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SUMMARY 


Purpose 

The  Institute  for  Defense  Analyses  (IDA)  was  tasked  by  the  Department  of  Defense 
(DoD)  to  study  information  infrastructures  for  enterprise  integration.  Two  documents 
resulted,  IDA  Paper  P-2664,  Information  Infrastructures  for  Integrated  Enterprises,  and 
IDA  Document  D-1386,  Current  Standardization  and  Cooperative  Efforts  Related  to 
Industrial  Information  Infrastructures.  The  information  presented  here  in  this  document 
provides  an  assessment  and  a  baseline  of  85  key  standards  and  technologies  that  will  be 
required  over  the  next  10  years  to  build  the  necessary  components  of  an  information  infra¬ 
structure.  Both  public  and  proprietary  standards  are  reviewed  since  important  contributions 
to  an  information  infrastructure  will  come  from  both  sources.  A  brief  description  of  each 
standard  and  technology  is  provided,  and  its  importance  to  information  integration  is 
assessed  along  with  its  current  status. 

The  team  set  out  to  accomplish  the  following  objectives: 

♦  Identify,  organize,  and  present  available  technology  components  from  which  a 
United  States  information  integration  strategy  can  be  coalesced.  These  technol¬ 
ogy  components  are  derived  from  current  standards  and  from  standardization 
and  pre-standardization  efforts. 

•  Identify  specific  opportunities  to  accelerate  the  development  and  adoption  of 
components  and/or  to  increase  the  likelihood  of  their  success. 

Scope  and  Methodology 

The  analysis  of  critical  standards  and  technologies  depends  heavily  on  the  choice 
of  a  framework  or  a  reference  model  for  expressing  “what  the  customer  wants.”  The  use  of 
requirements  derived  from  business  needs  can  be  defended  as  reflecting  the  wants  and  per¬ 
ceptions  of  those  who  must  ultimately  pay  the  bill  for  enterprise  integration.  It  also  includes 
the  organization,  procedural,  and  personnel  aspects  of  enterprise  integration,  as  well  as  the 
technical  ones. 


The  approach  also  takes  a  broad  view  of  the  importance  of  standards  and  technolo¬ 
gies  in  meeting  the  general  needs  of  an  information  infrastructure.  It  does  not  differentiate 
between  standards  and  technologies  with  a  broad  scope  and  those  addressing  a  narrow  set 
of  requirements. 

Using  the  baseline  data,  a  number  of  useful  questions  concerning  the  status  of  stan¬ 
dards,  technologies,  organizations,  and  programs  relevant  to  information  infrastructures  for 
enterprise  integration  can  be  answered  directly.  Examples  of  such  questions  include  the  fol¬ 
lowing: 

•  What  organizations  and  programs  are  concerned  with  information  modeling? 

•  What  standards  and  technologies  are  proposed  or  in  place  concerning  user  inter¬ 
faces? 

•  What  organizations  and  programs  are  involved  with  POSIX  (Portable  Operating 
System  Interface  for  Computer  Environments),  and  what  are  their  interests? 

Other  questions,  such  as  “Which  of  the  standards  and  technologies  are  most  critical 
to  success  in  implementing  a  National  Information  Infrastructure,  and  what  is  their  current 
status,”  cannot  be  answered  directly  from  the  baseline  data.  They  require  further  analysis 
and  often  additional  data.  The  specific  analytic  techniques  needed,  of  course,  depend  on  the 
question  being  asked.  Consequently,  the  document  presents  an  example  analysis  of  the 
question  just  raised,  to  demonstrate  the  types  of  analyses  possible  with  the  baseline  data. 

Findings  and  Conclusions 

A  generic  view  of  manufacturing,  adapted  from  the  Advanced  Manufacturing  Tech¬ 
nology  (AMT)  Standards  Reference  Model  [1],  provided  a  convenient  way  to  categorize 
activities  engaged  in  by  the  various  organizations  and  programs  and  to  characterize  the 
activities  to  which  particular  standards  and  technologies  pertain.  Ten  technical  categories 
were  used  in  this  study;  Integration  Frameworks  and  Architectures,  Operating  Systems  and 
Distributed  Environments,  Communications,  Data  Management  Systems,  Application 
Development  Tools  and  Methods,  Data  Representations,  Information  Modeling  Tools  and 
Methods,  User  Interfaces,  Programming  Languages,  and  Security  Tools  and  Methods. 

Integration  Frameworks  and  Architectures  and  Operating  Systems  and  Distributed 
Environments  are  critical  foundational  technologies  which  must  be  established.  These  cat¬ 
egories  scored  the  highest  across  all  evaluation  frameworks.  Several  potentially  important 
standards  and  technologies  were  identified.  Since  much  of  the  work  in  this  area  is  propri- 


etary  or  consortial,  there  is  still  a  need  to  promote  standards  in  these  areas.  The  lack  of  uni¬ 
fying  standards  may  lead  to  market  fragmentation  that  will  slow  the  development  of  an 
information  integration  infrastructure. 

Data  Management,  Communications,  and  Data  Representation  standards  and  tech¬ 
nologies  are  next  in  importance.  The  information  infrastructure  requires  standards  that  sup¬ 
port  highly  integrated  information  management  systems  across  the  entire  enterprise.  The 
need  for  standards  in  these  areas  has  long  been  recognized  as  evidenced  by  the  preponder¬ 
ance  of  standards  available.  There  is  still  a  need  to  organize  these  standards  into  a  consistent 
framework  and  to  ensure  that  they  are  compatible. 

Application  Development  Tools  and  Methods  and  Information  Modeling  Tools  and 
Methods  are  scored  as  equally  important  for  information  infrastructures  as  the  group  above. 
However,  standards  development  in  these  categories  is  less  advanced.  This  reflects  their 
focus  on  the  broader  process  of  translating  requirements  into  system  implementations,  rath¬ 
er  than  on  data  structures  within  those  implementations. 

Other  categories  such  as  User  Interface,  Programming  Languages,  and  Security 
Tools  and  Methods  are  also  important  Standards  and  technologies  in  some  of  these  cate¬ 
gories  are  more  important  in  the  development  of  applications.  Since  this  report  focused  on 
information  infrastructure,  they  did  not  score  very  high. 

The  importance  of  integration  frameworks  supports  the  necessity  of  identifying  a 
reference  model  that  can  be  used  to  guide  the  selection  of  standards  and  technologies  for 
an  integrated  information  infrastructure.  The  need  for  a  reference  model  is  widely  recog¬ 
nized.  Several  groups  are  developing  reference  models  in  this  area,  including  proprietary 
models,  vendor  models,  and  standards  efforts.  Consensus  is  needed  around  a  single  model 
(or  group  of  models)  from  which  a  coherent  set  of  standards  can  be  developed.  A  single 
reference  model,  with  its  benefits  for  analysis  and  decision-making,  does  not  imply  a  single 
view  of  information  integration.  Business  needs  vary  with  the  corporation,  its  market  sec¬ 
tors,  and  its  strategies.  It  is  unlikely  that  a  single  set  of  standards  will  emerge  to  fit  all  these 
varying  needs.  Still,  a  well-designed  reference  model  can  support  profiles  of  standards  suit¬ 
ed  for  different  needs  (such  as  the  use  of  the  Open  Systems  Interconnection  (OSI)  reference 
model  for  communication  standards). 

Further,  in  the  context  of  a  National  Information  Infrastructure,  needs  derived  from 
education,  health  care,  and  scientific  research,  among  other  areas,  will  also  be  important. 
Unexpected  uses  of  the  infrastructure  and  resulting  changes  in  the  way  the  nation  lives  and 


works  will  occur.  Any  reference  model  must  be  flexible  enough  to  incorporate  this  pattern 
of  infrastructure  development. 

It  is  important  to  maintain  a  sense  of  timing  and  evolution  about  infrastructure 
development.  The  U.S.  Air  Force  Enterprise  Integration  Program  is  an  effort  focused  on 
identifying  appropriate  responses  to  near-term  demands  for  information  integration.  Likely, 
these  responses  will  take  the  form  of  finding  ways  to  use  existing  and  near-term  standards 
and  technologies  more  effectively.  The  needs  anticipated  10  years  or  more  in  the  future 
appear  to  require  the  development  of  new  technologies  and  architectures  leading  to  systems 
of  autonomous  modules.  Also  the  development  of  strategies  and  methods  for  aiding  the 
transition  towards  these  forms  of  information  integration  must  be  planned  and  pursued. 
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1.  OVERVIEW 


The  American  business  environment  is  facing  a  significant  change  in  the  next  10 
years.  Individual  companies  are  moving  towards  greater  levels  of  integration,  both  inter¬ 
nally  and  with  their  suppliers  and  customers.  In  this  century,  the  nation  laid  out  a  long-term 
plan  for  a  network  of  national  highways  that  today  provide  a  critical  infrastructure  for 
defense  mobility  and  for  linking  companies  to  their  suppliers  and  customers.  Today  we  face 
a  similar  need  for  an  information  infrastructure  to  enable  the  integration  of  information  in 
and  among  enterprises.  One  of  the  biggest  challenges  facing  the  development  of  this  infra¬ 
structure  is  the  identification  and  development  of  the  necessary  standards  and  technologies. 

Information  technologies  have  matured  to  the  point  where  they  provide  sufficient 
support  for  today’s  required  “integrating”  tasks,  and  they  have  great  potential  for  continued 
development  of  powerful  capabilities.  One  need  only  pick  up  any  computing  periodical  to 
be  overwhelmed  by  both  the  multitude  of  products  available  and  the  many  advances  being 
achieved. 

This  baseline  report  has  the  following  objectives: 

•  Identify,  organize,  and  present  available  technology  components  from  which  a 
United  States  information  integration  strategy  can  be  coalesced. 

•  Identify  specific  opportunities  to  accelerate  the  development  and  adoption  of 
components  and/or  to  increase  the  likelihood  of  their  success. 

In  support  of  these  objectives,  this  report  includes  the  following: 

•  An  overview  of  programs,  standards  (both  officially  sponsored  and  de  facto), 
and  standards  organizations. 

•  An  analysis  of  the  deployment  (development  and  market  building)  of  a  selec¬ 
tion  of  standards  and  technologies. 

•  An  example  analysis  identifying  critical  standards  and  their  status. 


This  report  provides  the  reader  with  an  assessment  of  key  standards  and  technolo¬ 
gies  (STs)  that  will  be  required  over  the  next  10  years  to  build  the  necessary  components  of 
the  information  infrastructure.  It  establishes  a  baseline  of  STs,  documents  the  organizations 
and  programs  (OPs)  that  support  them,  classifies  each  technology’s  contribution  to  the  total 
integration  picture,  and  assesses  its  importance  to  the  needs  of  enterprise  integration  and  its 
current  status.  This  assessment  provides  insight  in  developing  strategies  for  the  most  criti¬ 
cal  STs  required  to  establish  a  successful  information  infrastructure. 

This  report  has  four  sections  and  five  appendices.  The  first  section  is  this  overview. 
The  second  section  establishes  a  “baseline”  of  data  documenting  a  broad  array  of  informa¬ 
tion-oriented  standards  and  technologies.  It  summarizes  information  contained  in  the  pro¬ 
files  of  OPs  described  in  Appendix  A.  These  profiles  describe  the  primary  OPs  that  are 
behind  these  STs.  This  section  also  summarizes  the  brief  synopses  of  STs  pertinent  to  build¬ 
ing  an  information  infirastructure  as  given  in  Appendix  B.  The  report  looks  at  both  private 
and  public  technologies  since  elements  of  a  total  solution  may  come  from  either  source. 
Critical  elements  existing  only  as  proprietary  solutions  help  to  identify  where  new  stan¬ 
dards  efforts  may  be  needed.  The  second  section  also  references  data  on  the  standards 
deployment  activities  of  OPs  as  presented  in  Appendix  C.  This  information,  identifying 
OPs  involved  in  technology  development  and  market  building  for  standards,  is  useful  in 
promoting  appropriate  development  and  transfer  strategies. 

Standards,  technologies,  organizations,  and  programs  (STOPs)  are  defined  as 
broadly  as  possible  in  this  report.  Thus,  there  may  be  overlaps  in  definition  or  categoriza¬ 
tion.  The  categorization  is  meant  as  an  aid  to  organizing  the  vast  amount  of  information  on 
this  subject,  not  as  a  definitive  classification  scheme.  In  this  report  “organizations”  and 
“programs”  refer  to  the  companies  and  efforts  that  are  behind  the  development  and  deploy¬ 
ment  of  STs. 

In  the  third  section,  example  analyses  identify  critical  STs  and  their  current  status. 
The  analyses  uses  a  model  based  on  the  Quality  Function  Deployment  (QFD)  methodology. 
QFD  is  a  sfructured  technique  for  articulating  needs,  relating  needs  to  means  for  meeting 
those  needs,  and  detecting  complementing  and  conflicting  requirements.  The  methodology 
requires  scoring  the  fit  of  solution  features  to  requirements.  The  model  used  here  is 
described  in  sufficient  detail  that  others  could  use  their  own  scoring  criteria  to  generate  dif¬ 
ferent  analyses.  The  intent  is  to  provide  a  useful  first-cut  identification  of  areas  needing 
work,  along  with  a  tractable  method  for  understanding  the  rationale  behind  the  choices. 
Data  for  the  analyses  is  drawn  from  this  report's  baseline  and  from  related  work  such  as  the 
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on-going  Enterprise  Integration  Program  (EIP)  and  the  National  Institute  of  Standards  and 
Technologies  (NIST)  Application  Portability  Profile  (APP). 

The  analyses  identify  potential  STs  that  are  critical  to  building  an  integrated  infor¬ 
mation  infrastructure.  Once  these  STs  are  identified,  the  charts  and  information  in  Section 
2  of  this  report  and  supporting  appendices  will  provide  further  definition  of  the  specific 
technologies,  the  organizations  behind  them,  and  the  potential  deployment  activities  where 
additional  development  could  significantly  leverage  the  success  of  those  STs. 

The  final  section  contains  a  number  of  observations,  conclusions,  and  issues  that 
resulted  from  this  effort. 

Overall,  the  report  documents  an  organized  perspective  on  activities  to  support  an 
information  infrastructure.  This  perspective  can  be  used  to  help  identify  key  aspects  about 
those  activities  requiring  further  development,  leading  to  the  realization  of  an  adequate 
U.S.  information  infrastructure. 

An  earlier  version  of  the  baseline  was  reviewed  with  an  external  panel  of  experts. 
This  report  incorporates  the  review  panel's  advice,  given  its  constraints  and  timetable. 
Guidance  was  given  in  two  directions:  the  need  for  identification  of  business  scenarios  that 
drive  enterprise  integration  applications,  and  the  necessity  of  choosing  and  applying  an 
architecture  or  framework  to  guide  the  selection  of  standards  and  technologies.  In  response 
to  the  first  issue,  the  report  uses  the  results  of  the  EIP  Needs  and  Requirements  Analysis, 
presented  in  Section  3.  In  response  to  the  second,  issue,  the  report  uses  technical  categories 
adapted  from  the  Advanced  Manufacturing  Technology  (AMT)  Standards  Reference  Mod¬ 
el  [1]  as  a  default  means  of  grouping  STs  in  the  context  of  information  infrastructures  for 
enterprise  integration.  The  report  does  not  intend  to  suggest  that  this  grouping  meets  the 
long-term  need  for  an  adequate  framework.  Discussion  of  the  need  for  a  standard  reference 
model  of  enterprise  integration  appears  in  Section  4. 


2.  ESTABLISHING  A  BASELINE 


This  section  presents  perspectives  of  current  major  efforts  to  develop  standards, 
technologies,  organizations,  and  programs  (STOPs).  An  examination  of  key  activities  with¬ 
in  these  efforts  has  resulted  in  the  documentation  of  a  baseline  of  these  STOPs.  This  base¬ 
line  serves  both  as  a  stand-alone  reference  and  as  input  data  for  further  analyses  (such  as 
Section  3). 

The  establishment  of  the  baseline  was  done  through  an  extensive  data  collection 
effort.  Information  was  gathered  from  other  reviews  both  in  the  literature  and  in  related  pro¬ 
grams  (such  as  the  EIP  Needs  Analysis  and  State  of  the  Art  Assessment  tasks).  Input  was 
also  obtained  from  the  Institute  for  Defense  Analyses  (IDA),  Microelectronics  and  Com¬ 
puter  Technology  Corporation  (MCC),  NIST,  and  the  review  panel  listed  at  the  end  of  the 
Preface.  Relevant  OPs  were  selected  and  examined.  These  include  both  official  standards- 
setting  organizations  and  organizations  that  are  involved  in  other  aspects  of  standards 
development  and  deployment.  Both  public  and  private  programs  were  also  considered 
when  their  primary  objective  was  the  establishment  of  some  standard  or  technology  com¬ 
ponent  of  the  information  infrastructure.  Information  STs  were  also  identified  and  exam¬ 
ined.  These  STOPs  were  then  researched  to  identify  their  significant  descriptive  attributes. 

One  of  the  objectives  of  creating  the  baseline  was  to  document  an  inventory  of 
STOPs  available  for  the  development  of  an  information  infrastructure.  To  help  assess  this 
inventory,  several  different  perspectives  on  the  baseline  data  were  created.  By  describing 
the  STOPs  from  various  perspectives,  different  aspects  of  these  complex  entities  are  more 
easily  highlighted  and  recognized. 

In  developing  the  baseline,  proprietary  and  de  facto  ST  were  included.  In  their  cur¬ 
rent  state,  such  STs  would  be  inadequate  in  providing  sufficiently  open  infrastructure  com¬ 
ponents.  Still,  two  reasons  make  their  inclusion  in  the  study  useful.  First,  they  represent 
capabilities  that  can  be  evaluated  to  provide  an  illustrative  reference.  Second,  it  may  be 
more  cost  effective  to  open  a  proprietary  ST  than  to  develop  a  functionally  equivalent  neu¬ 
tral  one. 


The  following  subsections  document  the  baseline,  describe  the  ways  data  are  for¬ 
matted,  and  give  the  related  rationale. 

2.1  BASELINE  DATA  PRESENTATION  FORMAT 

Items  that  constitute  the  baseline  are  referred  to  as  being  either  a  standard,  a  tech¬ 
nology,  an  organization,  or  a  program.  The  following  definitions  are  used  here; 

Standard;  A  definition  of  a  method  or  technique,  achieved  either  by  a  tangible 
specification  or  by  stable  implementations.  These  may  be  public  or  proprietary. 

Technology:  An  embodiment  of  a  method  or  technique  that  either  is  loosely  defined 
(e.g.,  in  early  development),  or  refers  to  a  broad  class  of  capabilities  (which  may 
involve  related  but  different  standards). 

Organization;  A  body  of  people  that  advances  the  development  of  STs  and  has  a 
permanent  existence  beyond  the  development  needs  of  any  particular  STs. 

Program;  A  body  of  people  that  advances  the  development  of  STs,  but  has  limited 
existence,  usually  tied  to  the  completion  of  a  phase  or  phases  of  ST  development. 

The  baseline  data  are  summarized  in  three  subsections  and  presented  in  detail  in 
three  appendices.  First,  Section  2.2  describes  several  organizing  concepts  used  to  clarify 
and  summarize  presentation  of  the  baseline  data.  Then,  Section  2.3  introduces  each  of  the 
organizations  and  programs  in  the  baseline.  Appendix  A  provides  more  detailed  profiles  of 
each  of  these  OPs.  Section  2.4  introduces  the  standards  and  technologies  in  the  baseline. 
Appendix  B  describes  each  of  these  STs.  Section  2.5  summarizes  the  relationships  between 
the  OPs  and  the  STs  by  identifying  which  OPs  drive  various  deployment  stages  of  major 
STs.  The  details  of  these  relationships  are  provided  in  Appendix  C.  Section  2.6  discusses 
possible  uses  of  the  baseline. 

2.2  ORGANIZING  CONCEPTS 

To  better  understand  the  interrelationship  among  STOPs,  it  is  useful  to  organize 
them  in  several  ways:  in  terms  of  integration  activities  within  an  enterprise,  in  terms  of 
views  of  the  enteiprise,  and  in  terms  of  the  deployment  activities  needed  to  successfully 
introduce  integration  technologies. 

A  generic  view  of  manufacturing,  adapted  from  the  AMT  Standards  Reference 
Model  [1],  provides  a  convenient  way  to  categorize  activities  engaged  in  by  the  various 
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OPs  and  to  characterize  the  activities  to  which  particular  STs  pertain.  The  ten  technical  cat¬ 
egories  used  in  this  study  are; 

•  Integration  Frameworks  and  Architectures:  Overall  integrating  representations, 
models,  and  schemas  of  the  enterprise  and  its  component  parts  (e.g.,  APP,  SAA, 
GM-C4  frameworks). 

•  Operating  Systems  and  Distributed  Environments:  Components  used  to  provide 
system  services  (I/O,  process  management,  and  others)  to  applications  (e.g.. 
Portable  Operating  System  Interface  for  Computer  Environments  (POSIX), 
Unix,  MS-DOS,  NetWare) 

•  Communications:  Components  used  to  connect  applications,  allowing  applica¬ 
tions  to  transfer  data  and  control  among  themselves  (e.g..  Open  Systems  Inter¬ 
connection  (OSI)  and  Transmission  Control  Protocol/Intemet  Protocol  (TCP/ 
IP)). 

•  Data  Management  Systems:  Components  used  to  store,  manage,  and  retrieve 
data.  Data  management  includes  knowledge  bases,  database  management  sys¬ 
tems  (DBMS),  information  management  systems,  data  dictionaries,  and  schema 
implementations. 

•  Application  Development  Tools  and  Methods:  Tools  and  methods  used  to  mod¬ 
el  and  build  applications  (e.g.,  application  generators). 

•  Data  Representations:  High-level  data  representation  standards  (e.g.,  STandard 
for  the  Exchange  of  Product  data  (STEP)  and  Electronic  Data  Interchange 
(EDI)). 

•  Information  Modeling  Tools  and  Methods:  Tools  and  methods  used  to  construct 
models  of  the  enterprise  and  its  components  (e.g..  Integrated  Computer-Aided 
Manufacturing  (ICAM)  Definition  Language  (IDEE)  and  Semantic  Unification 
Meta-Model  (SUMM)). 

•  User  Interfaces:  Components  that  allow  users  to  interact  with  the  applications 
making  up  the  integrated  enterprise  (e.g..  Motif  and  X/Windows). 

•  Programming  Languages:  High-level  languages  used  to  represent  algorithms. 
This  category  includes  APPs  (e.g.,  Ada  and  C+-I-). 

•  Security  Tools  and  Methods:  Tools  and  methods  used  to  control  access  to  appli¬ 
cations  and  data  (e.g.,  Kerberos). 


An  second  way  of  organizing  baseline  STs  is  in  terms  of  the  view  of  enterprise  inte¬ 
gration  for  which  the  ST  is  relevant.  The  three  views  used  here  are  as  follows: 

•  Business  View:  View  of  an  enteiprise  held  by  the  technology  user.  It  is  based 
on  the  concept  of  looking  at  a  tool  (software  or  otherwise)  as  a  means  to  an  end, 
with  no  concern  for  how  the  tool  actually  works.  The  business  view  includes 
satisfying  enterprise  goals,  justification  requirements,  performance  measure¬ 
ment,  and  organizational  activity  support.  For  this  view,  the  overall  function  of 
a  tool  is  important,  not  the  underlying  technology. 

•  Information  View:  View  held  by  information  management  specialists.  It  is  con¬ 
cerned  with  data  flow  within  the  enterprise.  The  Information  View  looks  at 
where  data  comes  from  and  where  it  must  go,  but  not  how  it  moves. 

•  Technology  View:  View  of  an  enterprise  that  encompasses  the  standards  and 
devices  used  to  implement  and  execute  applications. 

A  third  organizing  concept  is  the  sequence  of  deployment  activities  needed  for  suc¬ 
cessful  technology  development  and  market  building.  Eight  deployment  activities  are  con¬ 
sidered  in  this  report: 

Technology  Development 

•  Modeling:  Which  OPs  are  responsible  for  developing  the  models  used  by  the 
ST. 

•  Standards:  Which  OP  is  responsible  for  developing  the  standard  associated  with 
the  ST. 

•  Method/Tool:  The  OPs  that  are  developing  methods  or  tools  which  use  and  sup¬ 
port  the  ST. 

•  Prototype:  Which  OPs  have  developed  prototype  systems  using  the  ST. 

•  Standard  Validation/Demonstration:  Which  OPs  are  involved  in  validation  or 
demonstrations  of  the  ST. 

Market  Building 

•  Ph-oduct  Certification:  Which  OPs  are  responsible  for  developing  tests  or  certi¬ 
fying  products  that  use  the  ST. 

•  User  Guidelines:  Which  OPs  are  developing  guidelines  on  how  to  best  use  the 
ST. 
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•  Awareness  and  Education:  Which  OPs  are  working  to  increase  user  awareness 
of  the  ST. 

2.3  OPs  PROFILES 

Profiles  in  Appendix  A  provide  an  overview  of  each  of  the  27  organizations  and 
programs  included  in  the  baseline  study.  Each  profile  has  two  parts:  a  matrix  and  accompa¬ 
nying  textual  information.  The  matrix  relates  the  activities  engaged  in  by  that  OP  to  the 
technical  categories  and  to  the  view  of  enterprise  integration  introduced  above.  The  text 
provides  non-technical  profile  information  about  that  program  or  standards  organization. 
An  overview  table.  Table  1,  “Organization  Summary  Chart,”  on  page  11,  summarizes  for 
each  of  the  organizations  the  areas  in  which  they  are  active. 

2.4  STs  BRIEFS 

ST  briefs  provide  a  succinct  description  of  standards  and  technologies  that  may 
affect  the  development  of  an  information  infrastructure.  The  85  STs  considered  in  this  study 
are  described  in  Appendix  B.  A  summary  listing  of  these  STs,  organized  under  the  10  tech¬ 
nology  categories,  appears  in  Table  2,  “Standards  Summary  Chart,”  on  page  13. 

2.5  OPs  DEPLOYMENT  FORCES 

Deployment  Force  matrices  indicate  which  OPs  are  involved  in  different  aspects  of 
developing  and  deploying  the  various  STs  in  the  baseline.  As  critical  STs  are  identified, 
these  matrices  show  which  OPs  may  benefit  from  assistance  with  deployment  activities. 
The  matrices  also  identify  critical  deployment  activities  that  still  require  a  sponsoring  OP. 
Deployment  Force  matrices  for  the  10  technical  categories  are  given  in  Appendix  C.  Table 
3,  “Deployment  Forces  Summary,”  on  page  15  summarizes  the  coverage  of  deployment 
activities  by  technical  category. 

2.6  USES  OF  BASELINE  DATA 

A  number  of  useful  questions  concerning  the  status  of  STOPs  relevant  to  informa¬ 
tion  infrastructures  for  enterprise  integration  can  be  answered  directly  from  the  baseline 
data  in  the  summary  charts  depicted  in  Table  1,  Table  5,  and  Figure  1,  and  in  more  detail  in 
Appendices  A,  B,  and  C.  For  illustration,  we  use  the  baseline  data  to  address  the  following 
questions: 

1 .  What  OPs  are  concerned  with  information  modeling? 

2.  What  STs  are  proposed  or  in  place  concerning  user  interfaces? 


3.  What  OPs  are  involved  with  POSIX,  and  what  are  their  interests? 

4.  Which  of  the  STs  are  most  critical  to  success  in  implementing  a  National  Infor¬ 
mation  Infrastructure? 

5.  What  is  the  completion  and  acceptance  status  of  the  critical  STs? 

The  first  question,  “What  OPs  are  concerned  with  information  modeling?”,  can  be 
answered  from  Table  1.  More  details  on  particular  OPs  can  be  found  in  Appendix  A. 

The  second  question,  “What  STs  are  proposed  or  in  place  concerning  user  interfac¬ 
es,”  can  be  answered  by  consulting  the  list  of  STs  grouped  by  technical  category,  to  be 
found  in  Table  2,  “Standards  Summary  Chart,”  on  page  13.  Descriptions  of  those  STs  can 
be  found  in  Appendix  B,  and  identification  of  OPs  actively  involved  in  deploying  specific 
STs  can  be  found  in  the  user  interface  technical  category  matrix  in  Appendix  C. 

To  answer  the  third  question,  “What  OPs  are  involved  with  POSIX,  and  what  are 
their  interests,”  requires  (1)  scanning  the  listing  of  STs  grouped  by  technical  category  in 
Table  2,  “Standards  Summary  Chart,”  on  page  13,  (2)  noting  the  category  of  POSIX,  and 
(3)  then  consulting  the  appropriate  technical  category  matrix  in  Appendix  C. 

Many  other  interesting  questions  (e.g.,  questions  4  and  5)  cannot  be  answered 
directly  by  consulting  the  baseline  data.  They  require  further  analysis  and  often  additional 
data.  The  specific  analytic  techniques  needed,  of  course,  depend  on  the  questions  being 
asked.  The  next  section  presents  analyses  of  the  two  questions  just  raised,  as  examples  of 
the  types  of  analyses  that  the  baseline  data  makes  possible. 
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Table  1.  Organization  Summary  Chart  (Continued) 
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Table  2.  Standards  Summary  Chart 


Category 

Integration  Frame¬ 
works  and  Archi¬ 
tectures 


Operating  Systems 
and  Distributed 
Environments 


Communications 


Data  Management 
Systems 


STs 


Portable  Common  Tool  Environment  (PCTE) 

CAD  Framework  Initiative  (CFI) 

Engineering  Information  System  (EIS) 

Genend  Motors  CAD/CAM/CAE/CIM  (GM-C4) 

Integrated  Computer-Aided  Manufacturing  Factory  of  the  Future  (ICAM-FoF) 
AD/Cycle 

Application  Portability  Profile  (APP) 

Systems  Application  Architecture  (SAA) 

Network  Applications  Support  (NAS) 

NewWave 


Portable  Operating  System  Interface  for  Computer  Environments  (POSIX) 
OSF/1 

System  V  Release  4  Unix  (SVR4) 

Microsoft  Disk  Operating  System  (MS-DOS) 

OS/2 

Mac  (Macintosh)  System  7 
Object  Management  Group  (OMG) 

Open  Distributed  Processing  (ODP) 

Distributed  Computing  Environment  (DCE) 

Object-Oriented,  Change-Oriented  Reference  Environment  (OO-CORE) 
Process-Oriented  Management  System  (POMS) 

ANSAWare 

Cimplicity 

Distributed  Object  Management  Facility  (DOMF) 

Object  Linking  and  Embedding  (OLE) 

NetWare 

LANManager 

Vines 


Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP) 

Manufacturing  Automation  Protocol/Technical  and  Office  Protocol  (MAP/ 
TOP) 

Government  Open  Systems  Interconnection  Profile  (GOSIP) 

Transparent  File  Access  (TFA) 

Netwoik  Computing  System/Remote  Procedure  Call  (NCS/RPC) 

Government  Network  Management  Profile  (GNMP) 

X.500 


Information  Resource  Dictionary  System  1  (IRDSl) 
Information  Resource  Dictionary  System  2  (IRDS2) 
Remote  Database  Access  (RDA)  Protocol 
SQL 

Object-Oriented  SQL  (00-SQL) 

Hypermedia 

Common  Data  Model  (CDM) 


Table  2.  Standards  Summary  Chart  (Continued) 


Category 

STs 
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X/Open  and  POSIX  APIs 

Development 

Integrated  Design  Support  System  (IDS) 

Tools  and  Methods 

Knowledge-Based  Systems  (KBS) 

Application  Generators 
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Electronic  Data  Interchange  (EDI) 
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Raster  Format 
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ICAM  Definition  language  lx  (IDEFlx) 

and  Methods 
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Jackson  System  Design  (JSD) 
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Table  3.  Deployment  Forces  Summary 
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3.  ANALYSIS  USING  THE  BASELINE  AND  RELATED  DATA 


This  section  illustrates  how  analysis  of  the  baseline  data  can  be  used  to  support  the 
process  of  developing  and  implementing  integrated  information  infrastructures.  To  do  so, 
we  analyze  example  questions  4  and  5  from  Section  2.6: 

•  Which  of  the  STs  are  most  critical  to  success  in  implementing  a  National  Infor¬ 
mation  Infrastructure? 

•  What  is  the  completion  and  acceptance  status  of  the  critical  STs? 

These  two  questions  relate  to  the  criticality  and  status  of  STs  relevant  to  enterprise 
integration.  Identification  of  STs  most  critical  to  implementing  a  national  information  infra¬ 
structure  can  help  sharpen  monitoring  efforts  and  direct  resource  allocation  decisions. 
Knowledge  of  the  relative  status  of  STs  can  indicate  where  additional  deployment  efforts 
are  needed  to  insure  timely  wide-spread  adoption  of  critical  STs. 

3. 1  DETERMINING  CRITICAL  STs 

The  approach  used  to  answer  the  question,  “Which  of  the  STs  are  most  critical  to 
success  in  implementing  a  National  Information  Infrastructure,”  is  to  relate  the  baseline 
STs  to  expressed  business  needs.  These  needs  represent  the  objectives  and  high-level  busi¬ 
ness  strategies  of  a  successful  integrated  enterprise.  This  relationship  is  established  in  a 
two-step  process,  first  relating  business  needs  to  activities  that  an  integrated  enterprise  may 
undertake  to  satisfy  those  needs,  and  then  relating  the  activities  to  supporting  technical  cat¬ 
egories  and  STs  within  categories.  The  analysis  presented  here  is  based  upon  work  done  by 
the  EIP  Needs  Analysis  team,  and  makes  use  of  the  Quality  Function  Deployment  (QFD) 
methodology. 

3.1.1  QFD  Methodology 

QFD  is  a  widely  accepted  methodology  used  in  design  to  evaluate  the  importance 
of  different  (potentially  conflicting)  solutions  in  meeting  system  requirements.  It  is  partic¬ 
ularly  valuable  when  there  are  many  variables  (needs  and  solutions)  involved.  Its  use  in  this 
report  allows  for  a  reasonably  consistent  analysis  of  the  complex  information  in  the  base- 
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line.  It  is  a  systematic  method  of  comparing  over  80  STs  in  meeting  the  demands  of  an  inte¬ 
grated  information  infrastructure.  The  results  of  analysis  can  be  easily  manipulated  (like  a 
spreadsheet)  to  determine  the  effects  of  different  profiles  of  business  needs  and  activities. 

The  basic  concept  of  QFD  is  to  relate  “what  the  customer  wants”  (needs  and 
requirements)  to  “how  product  features  meet  those  wants”  (solutions).  A  chart  is  used  to 
record  the  evaluation  of  how  each  solution  contributes  to  each  need  or  requirement.  Fur¬ 
ther,  QFD  supports  decomposition,  in  that  a  solution  at  a  higher  level  can,  in  turn,  be  con¬ 
sidered  a  need  at  a  lower  level  of  analysis.  In  this  analysis  to  identify  critical  STs,  “customer 
wants”  relating  to  “product  features”  translates  at  the  first  level  into  “business  needs”  relat¬ 
ing  to  “activities,”  and  at  the  second  level  into  “required  activities”  relating  to  “STs”  (Fig¬ 
ure  1). 


Figure  1.  Relating  Business  Needs  to  Standards  and  Technologies 

In  a  QFD  matrix,  each  row  represents  a  need  or  requirement,  and  each  column  rep¬ 
resents  a  solution  feature.  At  the  intersection  of  each  need  and  solution,  a  symbol  is  placed 
representing  how  well  that  particular  solution  satisfies  that  particular  need. 

A  weighting  can  also  be  associated  with  each  need  or  requirement  (row)  indicating 
its  relative  importance.  (This  weighting  may  be  derived  from  higher  level  QFD  analyses.) 


The  weighting  and  individual  matrix  values  are  used  to  generate  a  total  score  for  each  solu¬ 
tion  (column).  This  score  indicates  the  overall  importance  of  a  particular  solution  in  meet¬ 
ing  the  weighted  needs. 

The  QFD  methodology  outlined  here  is  independent  of  the  specific  method  used  to 
evaluate  the  fit  of  solutions  to  needs,  and  a  number  of  different  methods  have  been  used  in 
industrial  practice.  The  methods  used  in  this  report  are  discussed  in  the  following  section. 

3.1.2  EIP  Requirements  Matrices 

As  noted  above,  the  EIP  Needs  Analysis  team  developed  two  levels  of  QFD  charts 
to  correlated  high  level  business  needs  to  specific  technologies  meeting  those  needs.  The 
process  used  by  the  EIP  team  in  developing  their  list  of  business  needs  and  requirements  is 
described  in  their  report.  Needs  Analysis  and  Requirements  Definition.  At  the  time  of  this 
study,  both  charts  were  still  in  draft  form,  but  their  form  as  presented  here  is  adequate  to 
illustrate  this  analysis. 

Both  the  EIP  Needs  Analysis  team  and  the  IDA  team  maintained  close  communi¬ 
cation  throughout  their  projects  to  ensure  maximum  leverage  of  each  other’s  work.  Toward 
that  end,  a  common  list  of  STOPs  was  used  by  each  team.  However,  due  to  the  difference 
in  scope  and  objectives  of  the  two  projects,  the  second-level  charts  (relating  required  activ¬ 
ities  and  STs)  differ  in  some  minor  ways.  Some  needs  and  requirements  not  directly  related 
to  information  infrastructure  were  dropped  from  the  matrix  presented  here,  and  some  rele¬ 
vant  standards  were  added. 

The  QFD  chart  relating  needs  to  requirements  is  presented  in  Figure  2.  Brief 
descriptions  of  the  needs  and  requirements  are  given  in  Appendix  D.  These  definitions  of 
needs  and  requirements  are  the  result  of  EIP  program  efforts  to  define  generic  business 
functions  and  distill  their  effects.  They  are  intended  to  capture  the  general  case,  and  may 
not  be  the  most  appropriate  for  all  situations.  For  a  first-cut  analysis  in  developing  an  infor¬ 
mation  infrastructure,  they  provide  a  useful  framework. 

The  following  example  describes  how  to  read  the  QFD  chart.  One  of  the  business 
needs  identified  (first  row)  is  Reduce  Life  Cycle  Cost  of  Information  Systems.  Looking 
across  that  row,  several  requirements  (columns)  intersect  that  row  with  a  symbol  shown  at 
the  intersection.  The  type  of  symbol  indicates  the  degree  of  importance  of  the  requirement 
to  meeting  the  business  need.  Requirements  such  as  Communication  Standards,  System! 
Network  Administration  Standards,  Data  Interchange  Standards,  Reuse  of  Knowledge  and 
Modules  have  high  importance  to  Reduce  Life  Cycle  Cost  of  IS.  Bounded  Customization, 
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Figure  2.  QFI)  Chart:  Business  Needs 
and  Requirements 
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Simplified  Processes,  etc.,  have  a  moderate  level  of  importance.  No  requirements  are 
shown  as  having  a  low  level  of  importance.  The  remaining  requirements  have,  in  this  anal¬ 
ysis,  little  importance  to  Reduce  Life  Cycle  Cost  of  IS. 

The  business  needs  (rows)  and  requirements  (columns)  were  developed  through  an 
interview  process  with  20  industry  experts.  These  experts  also  assigned  the  importance  rat¬ 
ings  to  each  business  need  and  the  matrix  weights  for  each  need-requirement  pair.  The 
Absolute  Importance  value  for  each  requirement  was  calculated  as  the  sum  for  that  require¬ 
ment  of  each  need’s  Importance  multiplied  by  the  weight  for  the  need-requirement  pair. 
Each  Absolute  Importance  value  was  then  revised  to  reflect  the  requirement's  interaction 
(complementary  or  conflict)  with  other  requirements.  The  resulting  Revised  Importance 
indicates  the  contribution  of  a  requirement  to  providing  solutions  for  the  full  set  of  business 
needs. 

The  QFD  chart  relating  requirements  to  technologies  is  presented  in  Figure  3.  The 
requirements  are  those  used  in  Figure  2.  Definitions  of  the  STs  can  be  found  in  Appendix  B. 

The  Importance  rating  for  each  requirement  (row)  in  Figure  3  are  the  Relative 
Importance  values  scaled  to  the  indicated  range  of  values.  The  matrix  weights  were  scored 
by  the  EIP  team  based  on  literature  search  and  interviews  with  industrial  experts  and  ven¬ 
dors.  The  final  Importance  values  for  technologies  and  standards  were  derived  using  the 
same  weighted  sum  calculation  described  above  for  Figure  2.  Both  QFD  charts  are  still  in 
draft  form,  and  further  review  may  lead  to  some  changes  in  scoring. 

The  information  presented  in  Figure  3  is  summarized  in  Table  4,  which  presents  a 
ranking  of  the  technology  categories.  This  table  shows  the  relative  importance  of  the  cate¬ 
gories  to  the  EIP  needs.  The  score  is  the  weighted  sum  of  the  maximum  score  within  that 
category  for  each  row  in  Figure  3  normalized  from  0  to  10  and  rank  ordered. 
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Figure  3.  QFD  Chart:  Requirements  and  Technologies 
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Table  4.  EIP  Category  Ranking 


Technology  Category 

Relative  Score 

Integration  Frameworks  and  Architectures 

10.0 

Operating  Systems  and  Distributed  Environments 

9.5 

Communications 

6.6 

Data  Management  Systems 

6.5 

Application  Development  Tools  and  Methods 

5.5 

Data  Representations 

5.4 

Information  Modeling  Tools  and  Methods 

4.8 

User  Interfaces 

2.3 

Programming  Languages 

2.3 

Security  Tools  and  Methods 

1.8 

Table  5  ranks  each  of  the  STs  within  a  given  category  by  their  total  score  from  the 
QFD  matrix,  normalized  to  a  scale  of  0  to  10.  This  table  shows  the  relative  importance  of 
STs  within  a  category. 

3.2  DETERMINING  THE  STATUS  OF  STS 

The  approach  used  to  answer  the  question,  “What  is  the  completion  and  acceptance 
status  of  the  critical  STs,”  is  to  relate  the  baseline  STs  to  1 1  aspects  of  the  development  and 
successful  deployment  of  a  standard  or  technology.  The  analysis  uses  criteria  obtained  from 
the  NIST  APP  and  POSIX  Open  Systems  Environment  (OSE)  [3],  with  some  additions  by 
the  IDA  team,  and  employs  the  QFD  methodology  introduced  previously. 

3.2.1  Methodology 

The  1 1  criteria  used  in  this  analysis  are  specification  availability,  level  of  consensus, 
product  availability,  completeness,  maturity,  stability,  de  facto  usage,  problem/limitation- 
freeness,  conformance  testing,  future  plans,  and  predominance.  These  criteria  and  how  they 
are  scored  are  described  in  more  detail  in  Appendix  E. 

The  scores  are  derived  in  two  ways.  The  NIST  APP  document  scores  some  of  the 
STs  in  the  baseline,  and  these  scores  were  used  directly  in  the  matrix.  The  others  STs  were 
scored  by  the  IDA  team  through  interviews  and  literature  reviews. 


Table  5.  Standards  and  Technologies  by  Category 


Category 

Technology 

Integration  Frameworks 

NAS 

GM*C4 

APP 

&  Architectures 

New  Wave 

SAA 

CFI 

Operating  Systems  & 

OO-CORE 

OMG 

DCE 

Distributed  Environments 

OSF/1 

SVR4 

NetWare 

Communications 

MAP/rOP 

GOSIP 

TCP/ff 

X.500 

Data  Management  Systems 

00-SQL 

IRDS2 

RDA  Protocol 

SQL 

IRDSl 

Application  Development 

Tools  &  Methods 

PlantWorks 

KB  Systems  (Application  Development) 

Application  Generators 

IDS 

X/Open  +  POSK  APIs 

Data  Representations 

STEP 

SGML 

EDI 

Tnfnrm^itinn  K4r>Hplino 

KB  Systems  (Info.  Tools) 

SUMM 

Tools  &  Methods 

Yourdon 

IDEFIX 

IDEFO 

User  Interfaces 

POSIX  1201  (XVT) 

Motif 

Open  Look 

X'Windows 

Programming  Languages 

Ada 

C++ 

c 

Fortran 

POSIX  1003.6 

Security  Tools  &  Methods 

DES 

Kerberos 

Importance 


10.0 


9.2 


9.0 


8.9 


26 


3.2.2  ST  Status  Matrix 


The  QFD  chart  relating  STs  to  status  criteria  is  presented  in  Figure  4.  The  scores  for 
each  ST  are  summed  to  give  an  overall  relative  status  rating. 

3.3  SUMMARY  OF  RESULTS :  CRITICAL  STs  AND  THEIR  STATUS 

Table  6  summarizes  information  from  Figure  4.  For  most  technical  categories,  a 
small  number  of  STs  dominate  in  order  of  importance.  Those  STs  are  included  in  this  table, 
as  are  a  few  STs  rated  of  medium  importance  but  with  high  relative  status. 

The  STs  are  divided  into  two  major  groupings:  Proprietary  and  Standards/Consor¬ 
tia.  Proprietary  technologies  are  those  products  or  technologies  developed  by  a  single  com¬ 
pany  or  a  closed  partnership.  Standards/Consortia  are  those  STs  developed  by  recognized 
standards  bodies  or  consortia  groups  whose  membership  is  open  to  anyone.  The  distinction 
helps  to  identify  if  the  important  technology  with  a  category  is  mostly  proprietary  (in  which 
case  standards  activities  may  need  to  be  started).  It  also  shows  where  investment  may  be 
applied  (towards  standards  and  consortia  as  opposed  to  proprietary  technologies). 

Key  STs  are  summarized  for  each  category: 

•  Integration  Frameworks  and  Architectures:  This  category  is  characterized  by 
the  relative  absence  of  standards  activity.  The  CAD  Framework  Initiative  (CFI) 
under  MCC  is  one  of  the  few  open  efforts  but  it  is  limited  to  a  particular  appli¬ 
cation  area.  An  “open”  framework,  similar  to  SAA,  NAS,  GM-C4,  or  New¬ 
Wave,  needs  to  developed.  The  NIST  APP  is  a  start,  though  it  tends  to  be  a 
collecting  framework  rather  than  an  integrating  one. 

•  Operating  Systems  and  Distributed  Environments:  Three  different  types  of 
functional  sub-areas  require  attention:  traditional  operating  systems,  distributed 
environments,  and  distributed  object  management  systems.  Unix  derivatives  are 
the  primary  contenders  for  the  traditional  operating  system.  SVR4  from  Unix 
International  and  OSF/1  from  the  Open  Software  Foundation,  both  of  which  ref¬ 
erence  the  POSDC  standard,  scored  well  in  this  evaluation.  The  many  deriva¬ 
tives  of  Unix  being  developed  emphasize  the  importance  of  moving  the  POSIX 
efforts  forward  so  that  a  common  standard  exists.  Both  of  these  operating  sys¬ 
tems  are  beginning  to  develop  capabilities  to  support  distributed  environments 
as  well.  A  key  contributor  in  this  area  is  the  Open  Distributed  Processing  (ODP) 
effort  begun  by  the  International  Organization  for  Standardization  (ISO)  to 
develop  a  reference  model  as  a  basis  for  future  distributed  processing  standards. 
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Figure  4.  ST  Status  Matrix 
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Predominance 


Table  6.  Important  STs  by  Category 


Proprietary 

Integration 

Frameworks 
and  Architectures 

10.0 

NAS 

GM-C4 

SAA 

NewWave 

Operating  Systems  and 
Distributed  Environ¬ 
ments 

9.5 

OO-CORE 

NetWare 

DCE 

Communications 

6.6 

Data  Management 
Systems 

6.5 

00-SQL 

Application 

Development 

Tools  and  Methods 

5.5 

PlantWorks 

KB  Systems 
Application  Gener¬ 
ators 

Data  Representations 

5.4 

Information  Modeling 
Tools  and  Methods 

4.8 

KB  Systems 

Yourdan 

User  Interfaces 

2.3 

Programming 

Languages 

2.3 

l£ 


tandards/Consortia 


OMG 

SVR4 

OSF/1 


MAP/TOP 

GOSIP 

TCP/IP 

X.500 


SQL 

IRDS2 

RDA 

IRDSl 


X/Open 

IDS 


STEP 

SGML 

EDI 


SUMM 

IDEFO 

IDEFlx 


POSIX  1201  (XVT) 
Motif 
Open  Look 
X-Windows 


Ada 

C++ 

c 

Fortran 


Security  Tools 
and  Methods 


1.8 


POSIX  1003.6 
DES 


Distributed  object  management  is  also  emerging  as  a  critical  technology  for  the 
future.  IBM  has  developed  OO-CORE  to  support  object  management.  The 
Object  Management  Group  (OMG)  is  also  heavily  involved  in  promoting  object 
standards  (such  as  the  Object  Request  Broker). 

•  Communications:  The  need  for  standards  in  the  area  of  communication  has  long 
been  recognized.  As  a  result  the  OSI  family  of  standards  (MAP/TOP/GOSIP) 
clearly  dominate  this  category.  TCP/IP  (which  was  often  the  third  member  of 
the  list)  must  also  be  considered  both  because  of  its  large  installed  base  and  open 
nature.  The  OSI  standards  define  more  functionality  than  TCP/IP,  but  TCP/IP  is 
on  a  trajectory  where  it  continues  to  adopt  OSI  functionality.  It  is  still  seen  by 
many  as  an  interim  step  to  full  OSI  compatibility. 

*  Data  Management  Systems:  The  first  ANSI  IRDS  standard  (IRDS 1 )  is  based  on 
the  relational  model.  It  defines  the  information  captured  by  an  Information 
Resource  Dictionary  as  well  as  the  services  provided  by  enterprise  processing 
facilities.  Future  object-oriented  systems  are  focusing  on  the  second  IRDS  stan¬ 
dard  (IRDS2)  that  is  under  consideration.  The  high  level  of  interest  in  this  work 
indicates  the  importance  of  promoting  this  relatively  young  effort.  The  Remote 
Database  Access  (RDA)  protocol  is  seen  as  an  important  standard  to  enable  the 
operation  of  distributed  databases.  IRDSl,  IRDS2,  and  RDA,  while  not  scoring 
particularly  well,  are  included  here  for  reasons  discussed  in  Section  3.4  on  page 
34.  00-SQL  is  an  object-oriented  extension  to  SQL.  It  is  used  as  the  data 
manipulation  language  developed  by  IBM  as  part  of  its  OO-CORE  project.  The 
importance  assigned  to  00-SQL  and  OO-CORE  indicates  the  need  to  bring 
these  technologies  into  the  public  arena  where  an  open  development  process  can 
take  place. 

*  Application  Development  Tools  and  Methods:  The  X/Open  APIs  define  a  tool¬ 
kit  of  program  interface  calls  across  a  number  of  functional  areas.  This  effort 
stands  out  in  its  effect  on  architectural  and  business  needs.  Also,  other  useful 
tools  and  methods  are  proprietary  in  nature,  such  as  application  generators  and 
knowledge-based  systems.  Although  seen  as  important,  there  is  little  or  no  stan¬ 
dards  activity  associated  with  these  areas. 

•  Data  Representation:  This  area  has  also  experienced  intense  standards  activi¬ 
ties.  There  are  many  different  data  representation  standards  that  are  specific  to 
an  application  area.  Combining  scores  across  a  spectrum  of  requirements 
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emphasizes  those  standards  that  have  the  broadest  scope  such  as  STEP  (the 
Standard  for  the  Exchange  of  Product  Data).  STEP  is  clearly  an  important  ISO 
effort  that  is  bringing  together  a  number  of  national  efforts  to  build  an  engineer¬ 
ing  data  exchange  specification.  Much  work  remains  in  the  development  of 
Application  Protocols  and  test  tools.  Other  representation  standards  that  are 
important  include  the  ANSI  Electronic  Data  Interchange  (EDI)  standards  for 
exchanging  business  documents.  Standard  Generalized  Markup  Language 
(SGML)  for  document  markup,  Programmer’s  Hierarchical  Interactive  Graph¬ 
ics  System  (PHIGS)  which  is  a  three-dimensional  graphics  standard  and  Com¬ 
puter  Graphics  Metafile  (CGM)  which  defines  a  graphics  file  format. 

•  Information  Modeling  Tools  and  Methods:  IDEFO  and  IDEFlx  are  important 
standards  for  process  and  information  modeling  for  large  organizations.  There 
are,  however  many  different  modeling  tools  available.  SUMM  is  an  effort  to 
define  the  mechanics  that  will  allow  integration  of  data  models  and  schema 
defined  by  various  modeling  languages.  Knowledge-based  systems  are  also 
being  used  for  information  modeling,  but  lack  any  significant  standards  activity. 

*  User  Interfaces;  X-Windows  is  a  key  standard,  which  is  also  found  integrated 
with  the  higher-level  functions  in  Motif  and  Open  Look.  Motif  (OSF)  and  Open 
Look  (Unix  International)  provide  extensive  libraries  for  building  graphical 
user  interfaces.  The  POSIX  1201  effort  is  important  because  it  is  attempting  to 
build  a  single  common  application  interface  (using  the  XVT  technology)  that 
sits  above  Motif  and  Open  Look. 

•  Programming  Languages;  This  area  already  has  a  number  of  well-developed 
standards  and  technologies  (Ada,  C,  Cobol,  Fortran,  Lisp)  and  primarily  needs 
only  maintenance.  Extensions  for  objects  (e.g.,  C-(-+)  or  APIs  (e.g,  X/Open)  are 
the  key  development  activities. 

*  Security  Tools  and  Methods:  POSEX  1003.6  is  a  key  standard  under  develop¬ 
ment  which  will  provide  comprehensive  security  access  and  control  for  appli¬ 
cations.  The  Data  Encryption  Standard  (DES)  is  now  part  of  GOSIP 
(Government  Open  Systems  Interconnection  Profile). 

The  current  status  of  the  STs  identified  in  Table  6  is  given  in  Table  7. 
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Table  7.  Status  of  Critical  STs 


Category 

Technology 

Importance 

Status 

NAS 

10.0 

5.8 

GM-C4 

9.2 

5.2 

Integration  Frameworks  and  Archi- 

APP 

9.0 

3.9 

tectures 

New  Wave 

8.9 

4.5 

SAA 

5.6 

5.6 

CFI 

5.4 

5.2 

OO-CORE 

7.7 

3.5 

OMG 

6.8 

3.7 

Operating  Systems  and 

DCE 

6.1 

5.8 

Distributed  Environments 

OSF/1 

5.0 

4.7 

SVR4 

4.6 

6.2 

NetWare 

3.3 

6.2 

MAP/TOP 

6.0 

Communications 

GOSIP 

6.4 

6.2 

TCP/IP 

3.9 

6.8 

X.500 

3.9 

7.4 

OO-SQL 

7.8 

3.9 

IRDS2 

4.0 

3.7 

Data  Management  Systems 

RDA  Protocol 

3.7 

2.7 

SQL 

2.8 

8.8 

IRDSl 

2.1 

PlantWorks 

3.1 

3.7 

KB  Systems  (Appli¬ 
cation  Development) 

2.9 

Application  Development 

Tools  &  Methods 

Application  Genera¬ 
tors 

2.6 

■■ 

IDS 

2.6 

2.7 

X/Open  +  POSIX 

APIs 

2.3 

6.2 
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Table?.  Status  of  Critical  STs  (Continued) 


Category 

Technology 

Importance 

Status 

Data  Representations 

STEP 

6.5 

3.3 

SGML 

3.6 

6.0 

EDI 

3.5 

7.4 

Information  Modeling  Tools  & 
Methods 

KB  Systems  (Info. 
Tools) 

4.4 

SUMM 

3.2 

2.5 

Yourdon 

2.1 

6.8 

IDEFIX 

2.1 

5.4 

IDEFO 

2.1 

5.4 

User  Interfaces 

POSIX  1201  (XVT) 

3.2 

2.7 

Motif 

2.9 

6.4 

Open  Look 

2.9 

5.6 

X-Windows 

2.4 

7.2 

Programming  Languages 

Ada 

2.7 

6.8 

C++ 

1.6 

5.4 

c 

0.9 

8.8 

Fortran 

0.7 

8.8 

Security  Tools  &  Methods 

POSIX  1003.6 

1.8 

2.5 

DES 

1.4 

6.6 

Kerberos 

0.9 
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An  artifact  of  using  broad  requirements  (business  or  technical)  is  that  the  results 
emphasize  those  STs  that  are  more  broadly  based.  However,  any  strategic  plan  must  con¬ 
sider  the  difficulty  of  integrating  these  STs  with  the  legacy  of  existing  and  future  propri¬ 
etary  solutions.  Systems  based  on  today’s  operating  systems  (MS-DOS,  VMS,  Unix), 
windowing  environments  (MS-Windows,  Macintosh),  and  networks  (Novell  and  TCP/IP) 
must  be  able  to  fit  within  the  information  integration  infrastructure.  In  fact,  there  has  been 
some  success  mixing  these  principal  components  to  construct  usable  information  infra¬ 
structures.  A  U.S.  information  infrastructure  must  support  these  and  other  very  popular 
technologies. 

3.4  COMMENTS  ON  THE  ANALYSIS 

The  analysis  of  critical  STs  and  their  current  status  presented  here  is  heavily  depen¬ 
dent  on  the  choice  of  framework  or  reference  model  for  expressing  “what  the  customer 
wants.”  The  use  of  requirements  derived  from  business  needs,  as  in  the  EIP  Needs  Analysis 
task,  can  be  defended  as  reflecting  the  wants  and  perceptions  of  those  who  must  ultimately 
pay  the  bill  for  enterprise  integration.  It  also  includes  the  organization,  procedural,  and  per¬ 
sonnel  aspects  of  enterprise  integration,  as  well  as  the  technical  ones. 

Other  evaluation  frameworks  could  be  used.  As  part  of  its  work,  the  IDA  team  pre¬ 
pared  similar  analyses  based  on  the  NIST  APP  Framework,  presented  in  the  NIST  Appli¬ 
cation  Portability  Profile  [2]  and  on  a  framework  representing  a  consensus  position  of  the 
EISWG.  Both  of  these  frameworks  focused  more  heavily  on  the  hardware  and  software 
aspects  of  enterprise  integration,  to  the  exclusion  of  organizational  and  personnel  ones. 
However,  the  relative  importance  of  the  technical  categories  was  quite  similar  in  all  cases, 
as  was  the  identification  of  critical  STs.  (In  the  Data  Management  Systems  category,  three 
STs  were  included  in  the  summary  table.  Table  6,  because  of  their  scores  in  these  other  anal¬ 
yses.) 

The  current  analysis  takes  a  very  broad  look  at  STs.  The  STs  in  the  baseline  vary  in 
their  breadth  (e.g.,  number  of  areas  covered  by  the  standard).  The  analysis  currently  favors 
STs  that  are  very  broad  in  their  scope.  Activities  such  as  GM-C4  and  NAS  tend  to  score 
high  because  they  receive  scores  for  many  different  need  areas.  Other  standards  that  are 
more  narrowly  focused  on  one  particular  set  of  needs  (such  as  STEP)  may  be  important, 
but  receive  a  lower  total  score. 

This  problem  can  be  corrected  by  comparing  STs  only  within  a  particular  element 
of  the  framework.  A  single  framework  element  can  be  elaborated  in  terms  of  its  specific 
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needs  and  the  STs  can  be  scored  for  how  well  they  meet  those  needs.  Then  a  comparison 
across  the  STs  can  determine  those  that  are  most  critical  in  fulfilling  that  particular  frame¬ 
work  requirement.  This  approach  will  provide  a  more  focused  analysis.  It  will  also  require 
a  better  definition  of  the  framework  or  architecture. 

Standards  must  also  be  analyzed  with  respect  to  their  compatibility.  Some  standards 
overlap,  others  are  cross-referenced.  Some  are  competing  (i.e.,  they  cannot  be  used  togeth¬ 
er),  others  are  complementary.  A  thorough  analysis  would  ideally  identify  a  complete,  con¬ 
sistent,  and  compatible  set  of  STs  for  each  element  within  the  framework,  a  set  that  is 
sufficient  for  meeting  the  requirements  of  the  framework.  This  type  of  analysis  is  difficult 
to  do  since  it  requires  detailed  knowledge  about  each  of  the  standards  and  their  interrela¬ 
tionships  and  compatibility.  Much  of  this  information  has  not  yet  been  collected. 

Once  a  standard  or  technology  is  identified  as  a  potential  development  target,  the 
ST  Status  Matrix  can  be  used  to  identify  its  weak  points.  A  specific  strategy  should  be 
developed  for  each  ST  to  help  improve  its  status  in  each  of  its  weak  areas.  For  instance,  a 
particular  standard  may  uniquely  address  a  need,  but  suffer  from  specification  instability 
and  not  be  well  known.  Alternatively,  a  technology  may  be  mature,  in  de  facto  usage,  but 
lack  standard  status  for  widespread  acceptance.  The  Deployment  Forces  summaries  in 
Appendix  C  can  also  be  consulted  for  an  ST  to  determine  the  relevant  organization(s) 
responsible  for  different  deployment  activities.  This  information  can  be  used  to  guide  the 
development  strategy 


4.  CONCLUSIONS  AND  ISSUES 


Building  the  U.S.  information  infrastructure  will  be  a  continual  effort.  Today’s  plan¬ 
ning  requires  understanding,  from  many  perspectives,  the  demands  for  and  capabilities  of 
information  technology.  This  report  attempts  to  establish  a  baseline  of  the  important  STs 
for  information  integration  and  the  OPs  behind  them.  The  information  in  this  report  repre¬ 
sents  the  start  of  an  analysis  of  the  critical  technologies  needed  to  support  integrated  enter¬ 
prises  within  the  next  decade.  It  identifies  some  key  areas  and  issues  that  must  be  addressed 
in  order  to  advance  infrastmcture  development. 

The  report  presents  a  model  for  evaluating  the  importance  and  status  of  any  stan¬ 
dard  or  technology.  The  model  is  presented  in  sufficient  detail  that  different  scores  can  be 
substituted  for  the  current  ones  based  on  additional  review  and  input,  allowing  future  work 
to  modify  the  results  of  the  model  to  include  new  or  more  accurate  information.  The  model 
can  also  be  extended  to  include  new  STOPs  as  further  information  becomes  available. 

4.1  CONCLUSIONS  FROM  ST  CRITICALITY  ANALYSIS 

The  analysis  presented  here  takes  a  broad  view  of  the  importance  of  STs  in  meeting 
the  general  needs  of  an  information  infrastructure.  It  does  not  differentiate  between  STs 
with  a  broad  scope  and  those  addressing  a  narrow  set  of  requirements.  With  that  caveat, 
some  general  conclusions  can  be  reached  from  this  analysis: 

•  Operating  Systems  and  Distributed  Environments  and  Integration  Frameworks 
and  Architectures  are  critical  foundation  technologies  which  must  be  estab¬ 
lished.  These  two  categories  scored  the  highest  across  all  evaluation  frame¬ 
works.  Several  potentially  important  STs  were  identified.  Since  much  of  the 
work  in  this  area  is  proprietary  or  consortial,  there  is  still  a  need  to  promote  stan¬ 
dards  in  these  areas.  The  lack  of  unifying  standards  may  lead  to  market  frag¬ 
mentation  that  will  slow  the  development  of  an  information  integration 
infrastructure. 

•  Data  Management,  Communications  and  Data  Representation  STs  are  next  in 
importance.  The  information  infrastructure  requires  standards  that  support 


37 


highly  integrated  information  management  systems  across  the  entire  enterprise. 
The  need  for  standards  in  these  areas  has  long  been  recognized  as  evidenced  by 
the  preponderance  of  standards  available.  There  is  still  a  need  to  organize  these 
standards  into  a  consistent  framework  and  to  ensure  that  they  are  compatible. 

•  Application  Development  Tools  and  Methods  and  Information  Modeling  Tools 
and  Methods  are  scored  as  equally  important  for  information  infrastructures  as 
the  group  above.  However,  standards  development  in  these  categories  is  less 
advanced.  This  reflects  their  focus  on  the  broader  process  of  translating  require¬ 
ments  into  system  implementations,  rather  than  on  data  structures  within  those 
implementations. 

•  Other  categories  such  as  User  Interface,  Programming  Languages,  and  Security 
Tools  and  Methods  are  also  important.  STs  in  some  of  these  categories  are  more 
important  in  the  development  of  applications.  Since  this  report  focused  on  infor¬ 
mation  infrastructure,  they  did  not  score  very  high. 

4.2  NEED  FOR  REFERENCE  MODEL 

The  importance  of  integration  frameworks  supports  the  necessity  of  identifying  a 
reference  model  that  can  be  used  to  guide  the  selection  of  standards  and  technologies  for 
an  integrated  information  inffastmcture.  A  detailed  reference  model  identifies  the  major 
architectural  elements  of  the  information  system  and  their  interrelationships.  It  also  pro¬ 
vides  a  framework  for  identifying  needed  interface,  representation,  or  other  standards.  It 
provides  an  organizing  structure  that  helps  to  characterize  the  STs  and  their  relationships. 

The  need  for  a  reference  model  is  widely  recognized.  As  a  result  several  activities 
are  developing  reference  models  in  this  area  including  proprietary  models  (GM-C4),  ven¬ 
dor  models  (EISWG),  and  standards  efforts  (CIM/OSA).  Consensus  is  needed  around  a  sin¬ 
gle  reference  model  (or  group  of  related  models)  from  which  a  coherent  set  of  standards 
can  be  developed.  These  models  must  be  driven  from  clearly  articulated  and  prioritized 
business  needs.  The  information  in  this  report  and  its  companion  reports  lays  the  founda¬ 
tion  for  capturing  some  of  these  critical  business  drivers.  Future  tasks  should  look  at  how 
well  these  business  needs  are  captured  in  current  and  emerging  reference  models. 

A  single  reference  model,  with  its  benefits  for  analysis  and  decision-making,  does 
not  imply  a  single  view  of  information  integration.  Business  needs  vary  with  the  corpora¬ 
tion,  its  market  sectors,  and  its  strategies.  It  is  unlikely  that  a  single  set  of  standards  will 
emerge  to  fit  all  these  varying  needs.  Still  a  well-designed  reference  model  can  support  pro- 
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files  of  standards  suited  for  different  needs  (such  as  the  use  of  the  OSI  reference  model  for 
communications  standards).  Future  analysis  should  look  at  this  question  in  greater  detail. 
Business  needs  should  be  captured  for  different  segments  of  the  industry  in  order  to  identify 
the  major  profiles  that  may  be  required  to  meet  those  needs. 

Further,  at  least  in  the  context  of  a  National  Information  Infrastructure,  other 
demands  besides  those  of  industrial  enterprise  integration  will  help  shape  the  infrastructure. 
A  national  information  infrastructure  is  viewed  by  many  as  doing  “...  for  the  flow  of  infor¬ 
mation — words,  music,  movies,  medical  images,  manufacturing  blueprints,  and  much  more 
— what  the  transcontinental  railroad  did  for  the  flow  of  goods  a  century  ago  and  the  inter¬ 
state  highway  system  did  in  this  century  ...  [it  can  be]  ...  a  national  resource  that  would 
improve  education,  health  care,  scientific  research,  and  the  ability  of  corporations  to  com¬ 
pete  in  the  world  economy,  among  many  other  things.”[5]  To  the  extent  that  analogies  with, 
for  example,  the  interstate  highway  system  are  accurate,  then  unanticipated  uses  of  the 
infrastmcture  and  resulting  major  changes  in  the  way  the  nation  lives  and  works  will  occur. 
Some  of  these  uses  and  changes  will  come  from  the  industrial  sector,  and  be  adopted  by 
others.  But  others,  equally  attractive,  will  come  from  outside  of  industry  and  be  adopted  by 
that  sector.  It  is  important  that  any  reference  model  be  flexible  enough  to  incorporate  this 
pattern  of  infrastructure  development. 

4.3  OTHER  ISSUES 

As  critical  STs  are  identified,  effective  deployment  strategies  must  be  put  in  place. 
It  is  never  sufficient  to  simply  bring  the  standard  to  approved  international  standard  status 
or  to  prototype  the  technology.  The  Deployment  Forces  Tables  (Appendix  C)  and  the  ST 
Status  Matrix  (Figure  5  on  page  27)  identify  some  of  the  activities  and  issues  that  determine 
the  success  or  failure  of  a  standard  or  technology.  A  strategy  to  deploy  critical  information 
technologies  must  take  these  issues  into  consideration. 

It  is  important  to  maintain  a  sense  of  timing  and  evolution  about  infrastructure 
development.  The  EIP  program  is  a  significant  effort  focused  on  identifying  appropriate 
responses  to  near-term  demands  for  information  integration.  These  responses  may  take  the 
form  of  finding  ways  to  use  existing  and  near-term  STs  more  effectively.  The  needs  antici¬ 
pated  10  years  or  more  in  the  future  appear  to  require  the  development  of  new  technologies 
and  architectures.  Also  the  development  of  strategies  and  methods  for  aiding  the  transition 
towards  these  forms  of  information  integration  must  be  planned  and  pursued. 
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APPENDIX  A.  ORGANIZATION  AND  PROGRAM  PROFILES 


Organizations  and  Programs  (OPs)  Profiled 

Automotive  Industry  Action  Group  (AIAG) 

American  National  Standards  Institute  (ANSI),  Inc. 

Application  Portability  Profile  (APP)  -  NIST  Program 

Computer  Integrated  Enterprise  (CIE)/Computer  Aided  Manufacturing  In¬ 
ternational  (CAM-I)  Program 

Computer-Assisted  Design  (CAD)  Framework  Initiative,  Inc.  (CFI) 
Corporation  of  Open  Systems  (COS) 

Enterprise  Integration  Program  (EIP) 

Engineering  Information  System  (EIS) 

Enterprise  Networking  Event  ‘88  International  (ENE  88i) 

Federal  Information  Processing  Standards  Publications  (FIPS  Pubs) 
Institute  of  Electronics  and  Electrical  Engineers  (IEEE),  Inc. 

Initial  Graphics  Exchange  Specification  (IGES) 

Integrated  Information  Support  System  (IISS) 

Information  Resource  Dictionary  System  (IRDS) 

Manufacturing  Automation  Protocol  (MAP)  and  Technical  Office  Protocol 
(TOP) 

National  Center  for  Manufacturing  Sciences/Computer  Integrated  Opera¬ 
tions  (NCMS/CIO) 

National  Institute  for  Standards  and  Technology  (NIST)  Shop  of  the  90s 
Open  Distributed  Processing  (ODP) 

Object  Management  Group  (OMG) 

Open  System  Foundation  (OSF) 

Open  System  Foundation/Distributed  Computing  Environment  (OSF/DCE) 

Product  Data  Exchange  Using  STandard  for  the  Exchange  of  Product  Data 
(STEP)  (PDES) 

Portable  Operating  System  Interface  for  Common  Environments  (POSIX) 

Remote  Data  Access  (RDA)  Protocol 

SEMATECH  Strategic  Cell  Controller  Project  (SCC) 

Transmission  Control  Protocol/Internet  Protocol  (TCP/IP) 

X/Open 


Outline 


The  profile  of  each  OP  consists  of  a  matrix  describing  activities  of  the  program  with 
text  providing  non-technical  profile  information.  Each  profile  follows  the  same  outline, 
although  not  every  section  is  available  for  every  OP. 

Title:  The  complete  title  of  the  organization  or  program. 

Scope:  A  summary  of  the  scope  of  work  in  which  the  OP  is  involved. 

Level  of  Effort:  The  type  of  membership,  support,  and  resources. 

Performers:  Who  is  involved  in  the  OP. 

Duration:  How  long  the  effort  has  been  in  existence. 

Primary  Milestones:  The  primary  deliverables  and  expected  dates  of  com¬ 
pletion. 

Intent:  The  mission  or  purpose  of  the  OP. 

Definitions:  Definitions  of  significant  terms  specific  to  this  OP. 

Description  of  Work  Done:  A  description  of  the  organization  and  a  sum¬ 
mary  of  the  standards  or  technologies  developed. 

Results:  The  significant  accomplishments  of  this  OP. 

Technology  Transfer  Approach  and  Plans:  What  activities  and  approach¬ 
es  are  being  taken  to  deploying  the  STs. 

Linkages:  The  relationships  and  links  maintained  by  this  OP  with  other 
OPs. 

References:  Location  for  additional  information  about  the  OP. 

Primary  Contacts:  Individuals  who  can  be  contacted  for  further  informa¬ 
tion  on  the  OP. 

Matrix  Notes:  Notes  on  information  presented  in  the  matrix. 


Title:  American  National  Standards  Institute  (ANSI),  Inc.  -  Organization 

Scope:  Supporting  development  of  information  technology  related  standards.  ANSI  is  the 
U.S.  technical  advisory  group  to  the  International  Organization  for  Standardization  (ISO). 

Level  of  Effort:  The  work  is  done  by  working  groups  composed  of  members.  The  work¬ 
ing  groups  are  sponsored  by  ANSI  and  work  items  are  picked  by  ISO  established  proce¬ 
dures. 

Performers:  Members  of  ANSI.  There  is  a  participation  fee  for  each  working  group. 
Duration:  Ongoing 

Intent:  To  develop  information  technology  related  standards  and  test  procedures.  The 
standards  are  published  by  ANSI/ISO. 

Description  of  Work  Done:  The  work  in  communications  is  related  to  Open  Systems 
Interconnection  (OSI),  Fiber  Data  Digital  Interface  (FDDI),  and  packet  switching.  In  the 
area  of  operating  systems,  ANSI  is  looking  into  the  Portable  Operating  System  Interface 
for  Computer  Environments  (POSIX)  work  of  the  Institute  of  Electronics  and  Electrical 
Engineers  (IEEE),  and  has  worked  on  graphic  and  database  management  standards.  It  has 
developed  standards  on  user  interface  and  human  factors,  and  has  worked  on  security  and 
several  programming  languages  (Ada,  Apt,  C,  Pascal,  Cobol,  Fortran,  Basic,  PL/1). 

Results:  Standards  have  been  published  in  the  above  mentioned  areas  except  for  POSIX. 

Linkages:  IEEE,  NEMA,  the  National  Institute  for  Standards  and  Technology  (NIST),  the 
Corporation  of  Open  Systems  (COS),  Manufacturing  Automation  Protocol/Technical  and 
Office  Protocol  (MAP/TOP). 


Table  A-1.  American  National  Standards  Institute  (ANSI)  Matrix 


Technical  Categories 


Business  View 


Information  View 


Title:  Application  Portability  Profile  (APP)  -  National  Institute  of  Standards  and 
Technology  (NIST)  Program 

Scope:  An  integration  mechanism  using  the  functionality  of  the  U.S.  Government’s  Open 
System  Environment  (OSE)  to  define  an  APP  in  terms  of  open  systems  specifications 
organized  into  major  service  areas.  The  OSE  functions  included  as  part  of  the  APP  are 
those  that  have  been  identified  as  important  to  a  broad  spectrum  of  Federal  agencies. 

Intent:  APP  is  not  a  standard.  APP  provides  guidance  to  assist  Federal  agencies  in  mak¬ 
ing  informed  choices  regarding  the  selection  and  use  of  OSE  specifications,  and  in  the 
development  of  application  profiles  based  on  the  APP.  It  is  directed  toward  managers  and 
project  leaders  who  have  the  responsibilities  of  procuring,  developing,  and  maintaining 
information  systems  supported  by  heterogeneous  application  platforms. 

Definitions: 

•  OSE.  A  conceptual  framework  that  provides  a  context  for  user  requirements 
and  standards  specification.  It  provides  a  set  of  information  system  building 
blocks  with  associated  interfaces,  services,  protocols,  and  data  formats. 

•  OSE  Reference  Model.  Establishes  a  context  for  understanding  how  the  dis¬ 
parate  technologies  required  as  part  of  an  OSE  relate  to  each  other.  It  also  pro¬ 
vides  a  mechanism  for  identifying  the  key  issues  associated  with  applications 
portability  and  interoperability. 

•  Profile.  A  selected  suite  of  specifications  that  define  these  interfaces,  services, 
protocols,  and  data  formats  for  a  particular  class  or  domain  of  applications. 

Description  of  Work  Done:  NIST  Special  Publication  500-187,  Application  Portability 
Profile,  describes  APP  as  the  U.S.  Government’s  OSE  profile.  The  report  describes  the 
service  areas  and  components  included  in  the  APP  and  provides  evaluations  of  recom¬ 
mended  specifications  for  the  majority  of  the  service  area  components.  One  of  the  conclu¬ 
sions  of  this  report  was  a  desire  to  see  all  of  the  OSE  specifications  take  the  form  of  a 
Federal  Information  Processing  Standard  (FIPS). 

Results:  Although  the  OSE  concept  is  relatively  new,  it  has  matured  to  the  status  of  an 
emerging  international  consensus  on  the  functionality  (i.e.,  the  collection  of  interfaces, 
protocols,  services,  and  supporting  formats)  that  should  be  included  in  an  OSE  (see  refer¬ 
ence  to  POSIX  below). 

Technology  Transfer  Approach  and  Plans:  There  is  a  shared  recognition  that  no  single 
vendor  can  supply  all  necessary  information  technology  systems  and  services.  The  need  to 


improve  portability  and  interoperability  has  resulted  in  widespread  interest  in  standards. 
By  understanding  and  using  APPs,  a  framework  can  be  developed  using  the  proper  stan¬ 
dards  and  information  technology  to  satisfy  specific  user  needs. 

Linkages:  Related  standards  for  APPs:  Portable  Operating  System  Interface  for  Common 
Environments  (POSIX),  Government  Open  Systems  Interconnection  Profile  (GOSIP), 
OSE  Reference  model,  OSE,  and  Open  Systems  Interconnection  (OSI). 

References: 

Emerging  Technologies  Group,  Inc.  An  Analysis  of  Application  Environments.  Dix  Hills, 
NY,  1989. 

X/Open  Company,  Ltd.  XIOpen  Portability  Guide.  Issue  3,  Volumes  1-7.  Englewood 
Cliffs,  NJ:  Prentice-Hall,  1988. 
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Title:  Automotive  Industry  Action  Group  (AIAG)  -  Organization 

Level  of  Effort:  Donated  time  from  member  companies  plus  modest  membership  fees 
based  on  company  gross  sales. 

Performers:  Both  administrative  and  technical  personnel  from  nearly  700  member  com¬ 
panies. 

Duration:  Ongoing,  begun  in  1982 

Primary  Milestones:  Numerous  white  papers  and  reports,  as  well  as  published  standards 
for  members  in  electronic  data  interchange  and  bar  coding. 

Intent:  The  purpose  of  AIAG  is  to  improve  productivity  in  the  automotive  industry.  It 
acts  as  a  forum  for  automotive  manufacturers  and  suppliers  to  reach  consensus  solutions 
to  common  business  needs. 

Description  of  Work  Done:  To  date,  a  number  of  standards  have  been  generated  involv¬ 
ing  the  exchange  of  information  between  companies.  Automotive  versions  of  electronic 
data  interchange  transaction  sets  and  bar  coding  are  examples  of  this.  In  most  cases,  AIAG 
has  used  the  approach  of  choosing  specific,  well  defined  subsets  of  standards  promulgated 
by  other  standards  bodies. 

Ongoing  work  includes  radio  frequency  identification  systems,  application  protocols  for 
IGES  data  transfers,  and  telecommunications  standards.  AIAG  is  also  studying  quality 
standards,  with  a  look  toward  rationalizing  the  current  piecemeal  system  in  the  automotive 
industry. 

Results:  Clearly  there  is  enough  interest  in  the  idea  of  such  an  organization  to  keep  AIAG 
going.  As  to  the  actual  adoption  and  use  of  its  standards  within  elements  of  the  automotive 
industry,  the  picture  is  not  so  clear.  A  wide  variety  of  companies  has  joined  and  main¬ 
tained  membership.  The  level  of  active  participation  at  the  individual  working  groups  is 
perhaps  a  better  indicator  of  the  interest  in  the  program,  but  is  unavailable. 

Technology  Transfer  Approach  and  Plans:  The  primary  technology  transfer  approach 
is  based  on  publication  of  white  papers  detailing  the  problems  and  publication  of  the  stan¬ 
dards  which  address  those  problems.  Standards  are  published  directly  and  publicized 
through  the  AIAG  monthly  magazine  and  through  direct  people  contact.  Since  the  AIAG 
management  and  technical  staff  are  on  loan  from  the  member  companies,  a  natural  link 
occurs  in  those  companies  who  participate.  In  addition,  the  working  groups  which  under- 


take  the  actual  standards  development  work  are  made  up  of  volunteers  from  the  member 
companies.  This  provides  another  avenue  for  moving  information  back  to  the  companies. 

Linkages:  Wherever  possible,  the  AIAG  bases  its  work  on  existing  national  and  interna¬ 
tional  standards.  Examples  include  ANSI  X12  for  electronic  data  interchange  and  IGES 
for  geometric  data  exchange. 

References:  Actionline,  monthly  publication  for  AIAG  members. 

Primary  Contact: 

Joe  Phelan,  Executive  Director 
AIAG 

26200  Lahser  Road,  Suite  200 
Southfield,  MI  48034 
(313)  358-3570 

Matrix  Notes: 

The  majority  of  AIAG’s  work  is  built  on  top  of  existing  standards.  It  typically  fmetunes  or 
selects  a  subset  of  an  existing  standard,  then  carefully  defines  its  use  for  the  automotive 
industry.  The  following  are  additional  notes  on  some  of  the  matrix  entries. 

•  Electronic  Data  Interchange  Transaction  Sets.  Standardized  transaction  sets 
based  on  ANSI  XI2  for  electronic  data  exchange  appropriate  to  automotive 
industry. 

•  Bar  Coding.  Bar  coding  standard  established  for  automotive  industry  for  auto¬ 
matic  identification  of  parts  and  documents. 

•  Radio  Frequency  Identification.  Non-optical  method  for  accomplishing  the 
same  purpose  as  bar  coding.  Automotive  standard  currently  being  established. 

•  Initial  Graphics  Exchange  Specification  (IGES)  Application  Protocols. 

Currently  developing  a  family  of  carefully  defined  subsets  of  the  IGES  data 
exchange  standard  to  serve  automotive  industry  needs. 
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Table  A-2,  Automotive  Industry  Action  Group  (AlAG)  Matrix 


Technical  Categories 

Business  View 

Information  View 

Technology  View 

Integration 

Fnimeworks  <"ind 
Architectures 

•  Automotive  DaUi 
Interchange  Models 

Operating  Systems  iind 

Distributed 

Environments 

Communications 

•  Electronic  DaUi 
Interchange 

•  Transaction  Sets 

•  Magnetic  Tape 
Labeling 

Dam  Miuiagement 
Systems 

•  Bar  Coding 

•  Radio  Frequency 
Identification 

Application 
Development  Tools 
and  Methods 

Data  Representations 

•  IGES  Application 

•  Protocols 

•  Non-Uniform 

•  Rational  B-Splines 

•  IGES 

Information  Modeling 
Tools  Jind  Methods 

User  Interfaces 

Prognunming 

Languages 

Security  Tools  and 
Methods 
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Title:  Computer  Integrated  Enterprise  (CIE)/Computer  Aided  Manufacturing- 

International  (CAM-I)  Program 

Scope:  CIE  focuses  on  the  management  approach  to  enterprise  integration.  The  mission  of 
the  CIE  group  is  “to  guide  enterprise  decision  makers  in  focusing  resources  towards 
achieving  strategic  business  goals  through  a  successful  management  approach  for  organi¬ 
zational  knowledge  and  technical  resource  utilization.” 

The  current  objectives  of  the  CIE  are  to: 

•  Be  the  premier,  world-wide  focus  for  defining,  analyzing  and  promoting  the 
CIE  concept. 

•  Provide  leadership  and  support  for  program  members  in  implementing  CIE  in 
their  companies. 

•  Create  a  common  understanding  and  acceptance  of  CIE. 

The  CIE  program  is  currently  focused  on  the  following  deliverables; 

•  CIE  guidelines  and  methods.  A  manual  for  implementing  enterprise  integration. 

•  Case  studies  of  best  implementations. 

•  An  extensive  digest  of  relevant  literature. 

•  Journeyman  Conferences.  Periodic  trips  and  findings  taken  by  the  CIE  group  to 
visit  enterprises  and  review  actual  implementations. 

•  Engineering  integration  decision  framework.  A  reference  model  for  decision 
making  in  the  process  of  implementing  and  operating  the  integrated  enterprise. 
This  is  thought  to  be  the  complementary  (organizational/implementation)  piece 
to  the  Computer  Integrated  Manufacturing/Office  System  Architecture  (CIM/ 
OSA). 

Level  of  Effort:  Membership  group  (14  sponsors  at  $22K  per  year  plus  about  1.5  person- 
months  of  labor  per  member  per  year).  It  has  been  working  on  this  program  for  three  years 
and  currently  are  planning  for  three  more  years.  The  group  contracts  out  about  three  per¬ 
son-years  of  work  per  year. 

Performers:  Members  and  university  affiliates.  Most  of  the  work  is  done  by  the  member 
representatives,  each  of  whom  dedicates  about  1.5  months  per  year.  In  addition,  some 
work  is  contracted  out  to  university  affiliates. 


Duration:  1988-1994 


Prime  motivation  for  initiating  the  CIE  CAM-I  membership  was  the  poor  rate 
of  return  on  investments  in  information  technology.  The  CIE  program  was 
designed  to  assist  a  group  of  peer  sponsors  from  industry  to  work  together  to 
understand  the  barriers  to  successful  integration  and  to  define  a  set  of  guidelines 
for  accelerating  the  pace  of  adoption.  Executive  forums,  reports,  and  the  Jour¬ 
neyman  Conferences  are  the  primary  mechanisms  for  technology  transfer  to 
members  and  their  executives  and  decision  makers. 

What  barriers  does  this  program  address? 

1.  Management  barriers.  Spheres  of  control  and  empowerment;  issues 
around  communication  and  understanding  of  goals;  and  the  ability  to  make 
timely  and  informed  decisions. 

2.  Organizational  barriers.  Bifurcation  of  functions  (design/manufacture); 
lack  of  standards  and  meaningful  measurements  of  performance;  excess, 
non-value-added  activities,  internal  competition,  cannibalization  of  autono¬ 
mous  organizations;  and  levels  of  hierarchy  and  communication. 

3.  Cultural  barriers.  Geographical;  implied  rules,  methods,  processes  “hand¬ 
ed  down”  by  tradition;  “not  invented  here”  (NIH)  syndrome;  education  and 
training;  and  lack  of  shared  goals. 

4.  Functional  barriers.  Lack  of  understanding  of  business  processes;  no 
change  “know-how”;  and  technology. 

5.  Strategic  barriers.  International  market  access  and  international  competi¬ 
tion;  poor  strategic  planning;  poor  interpretation  of  market  “signals”;  inef¬ 
fective  performance  measurement;  and  government  regulation  of 
international  trade. 

Will  the  CIE  program  lead  to  the  development  of  new  standards?  Yes,  manage¬ 
ment  methods  for  CIE  implementation  and  standards  for  decision  support  tools. 
CIE  is  also  collaborating  with  CIM/OSA  and  the  International  Organization  for 
Standardization  (ISO)  committee  TC184/SC5/WG1. 

What  were  the  original  project  objectives?  Develop  guidelines  and  methods  to 
support  the  implementation  of  CIE. 


Description  of  Work  Done: 

•  Digest  of  relevant  literature 

«  Journeyman  I&II  Conferences 

•  Guidelines  and  Methods  (version  1.1) 

•  Numerous  case  studies  of  “best  practice’’ 

•  First  draft  of  the  Decision  Framework 

The  work  of  the  CIE  is  primarily  done  through  study  groups  and  working  committees.  No 
new  methods  are  used  in  the  process  of  the  CIE  group.  However,  a  guideline  and  methods 
document,  to  guide  the  process  of  implementing  enterprise  integration,  is  a  specific  deliv¬ 
erable  of  the  CIE  group. 

Results:  As  stated  above,  the  primary  technical  transfer  mechanism  of  the  CIE  program  is 
directly  to  the  executives  and  decision  makers  in  the  member  companies.  Most  of  the  tan¬ 
gible  results  of  this  work  are  enterprise  integration  programs  and  projects  in  the  member 
companies. 

•  LTV  Aerospace  has  initiated  a  program  at  the  division  level. 

•  General  Dynamics  has  created  a  CIE  office  at  the  decision  level. 

•  Honeywell  and  Kodak  are  reported  to  have  corporate-level  programs  and  Gen¬ 
eral  Motors  is  using  pieces  of  the  CIE  model  in  several  plants  and  divisions. 

Cost  justification  criteria  are  outlined  in  the  guideline  and  will  be  carried  out  in  the  indi¬ 
vidual  member  pilots  and  programs.  It  should  be  noted  that  the  CIE  program  is  working 
jointly  on  measurements  of  strategic  deployment  and  measurements  of  the  extent  of  inte¬ 
gration  with  the  CAM-I  Cost  Management  System  program,  the  developers  of  the  activ¬ 
ity-based  costing  (ABC)  model.  The  focus  of  the  CIE  group  is  on  practice  rather  than 
products  so  it  is  unlikely  that  many  new  products  will  emerge  from  this  effort.  No  market 
studies  have  been  performed  to  gauge  market  interest  in  this  work.  Again,  as  a  member¬ 
ship-based  group,  the  primary  focus  is  transferring  technology  into  the  member  organiza¬ 
tions. 

CIE  is  now  beginning  to  develop  alliances  with  other  standards  bodies  and  consortia. 
They  are  willing  to  share  some  of  their  results  to  influence  standards  relating  to  the  techni¬ 
cal  architecture  for  enterprise  integration  and  CIM. 

Technology  Transfer  Approach  and  Plans:  The  major  focus  of  technology  transfer  are 
the  member  companies.  CIE  does  sponsor  conferences  for  executives  in  the  member  firms 
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plus  invited  guests.  In  addition,  the  CIE  group  hopes  to  participate  in  and  influence  the 
CIM/OSA  effort,  ISO’s  TC 1 84/SC5/WG 1 ,  the  Computer-Aided  Logistics  Support 
(CALS)  program,  and  the  Product  Data  Exchange  Standard  (PDES).  It  will  also  eventu¬ 
ally  publish  some  of  its  material  for  general  distribution. 

Near-term  and  long-term  plans: 

•  Complete  CIE  framework. 

•  Influence  TCI  84/SC5AVG 1 .  Several  detailed  papers  have  been  submitted. 

•  Build  links  to  other  consortia  for  collaborative  efforts  (Lehigh,  CAM-I/CMS, 
Microelectronics  and  Computer  Technologies  Corporation  (MCC),  National 
Center  for  Manufacturing  Sciences  (NCMS))  in  the  areas  of  standards  develop¬ 
ment  and  benchmarking. 

•  Retine  metrics  and  standards  for  implementation. 

•  Develop  detailed  specifications  for  decision  support  tools. 

Work  submitted  to  standards  committee:  CIE  has  submitted  several  responses  to  the  ISO 
committee  on  CIM  frameworks,  most  recently  the  response  to  TC184/SC5AVG1-N163, 
the  CEN/CENELEC  document,  based  on  CIM-OSA. 

Linkages: 

•  CIE  is  currently  linked  to  ISO’s  WG 1 .  It  is  interested  in  forming  links  with  the 
NCMS  Computer-Integrated  Operations  Special  Interest  Group  (CIO  SIG)  and 
with  MCC. 

•  Recently,  CIE  held  a  joint  working  session  with  the  CMS  group  in  CAM-I  to 
discuss  performance  measures  for  CIM. 

•  Internationally,  CIE  is  interested  in  forming  relations  with  several  ESPRIT 
projects  including  the  AMICE  CIM-OSA  and  the  Integrated  Modeling  of  Prod¬ 
ucts  and  Processes  Using  Advanced  Computer  Technologies  (IMPPACT).  Mr. 
Bob  Boykin,  the  Executive  Director  of  CIE,  is  an  action  officer  for  the  European 
CommunityAJnited  States  cooperative  initiative. 
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Table  A-3.  Computer  Integrated  Enterprise  (CTE)  Matrix 


Technical  Categories 


Business  View 


Integration  Frameworks 
and  Architectures 


Operating  Systems  and 
Distributed  Environment 


Communications 


Data  Management 
Systems 


Application 

Development  Tools  and 
Methods 


Data  Representations 


Infonnation  Modeling 
Tools  and  Methods 


User  Interface 


Decision  framework  for 
CIM  implementation 

Functional  8c  semantic 
models  (IDEF/NIAM) 

Guidelines  &  methods 
for  CIM 
implementation 

Managing  the  process 
of  change:  technically 
and  organizationally 


Information  View 


Tool  framework  for 
decision  support  and 
enterpnse  modeling 
tools 


Activity 

communication 

How  decisions  are 
communicated 


Corporate  strategy  for 
Data  Management 


None  yet.  Future 
interest  in  business 
methods 


Develop  semantic 
models  using  NIAM, 
business  models, 
information  models,  not 
technology 


Strategic  integration  of 
modeling  methods  for 
support  of  El  life  cycle 

ABC  risk  analysis 
simulation 

How,  when  to  make 
decisions 

What  is  the  topology/ 
taxonomy  of  enterprises 


Labor/Management. 

relations 

Organizational  issues  in 
adopting  new 
technology 


Electronic  mail  (email) 
Electronic  conferencing 


Working  toward  a 
business  development 
language 


Title:  CAD  Framework  Initiative,  Inc.  (CFI)  -  Organization 

Scope:  CFI  is  a  consortium  created  to  promote  standards  that  facilitate  and  enable  elec¬ 
tronic  computer-assisted  design  (CAD)  tool  integration.  Member  companies  include  tool 
vendors,  workstation  vendors,  semiconductor  suppliers,  and  end  users. 

Level  of  Effort:  International  consortium  of  50+  members,  including  8  CFI  Sponsor 
members.  The  membership  is  approximately  60%  North  American,  20%  European,  and 
20%  Asian.  The  eight  CFI  Sponsor  members  are  U.S.  corporations. 

Performers:  Most  of  the  technical  work  is  performed  by  more  than  200  volunteers  from 
member  companies  and  organizations.  CFI  has  a  staff  of  13. 

Duration:  Ongoing,  begun  in  1988 

Primary  Milestones: 

•  Founded  (November  1988) 

•  First  CFI  meeting  in  Europe  (October  1989) 

•  EuroCFl  and  CFI  Meeting  in  Japan  (CFIMJ)  formed  (April  1990) 

•  1 990  Integration  Project  Demonstrated  (Design  Automation  Conference  (DAC) 
1990) 

•  1991  Integration  Project  Demonstrated  (DAC  1991) 

•  CFI  Release  1.0  Pilot  Projects  (January-September  1992) 

•  Standards  for  Electronic  Design  Automation,  Release  1 .0  (December  1 992) 

•  CFI  Release  2.0  Pilot  Projects  (September  1993-March  1994,  projected) 

•  Standards  for  Electronic  Design  Automation,  Release  2.0  (June  1994,  project¬ 
ed) 

Intent:  Since  1988,  CFI  has  been  working  to  make  it  simpler,  faster,  and  less  costly  to  use 
design  automation  tools  and  design  data  by  developing  specifications  for  a  CAD  frame¬ 
work.  CFI’s  mission  is  to  define  and  support  the  adoption  of  standards  which  make  it  eas¬ 
ier  to  integrate  design  data  and  to  integrate  and  interoperate  design  automation  tools  for 
the  benefit  of  users  and  vendors  worldwide. 

Description  of  Work  Done:  CFI  defines  a  CAD  Framework  as  a  software  infrastructure 
that  supports  the  application  environment  for  CAD  tools.  While  recognizing  that  the 
design-tool  framework  concept  has  many  domain  independent  components  and  should  be 
broadly  applicable,  CFI  is  focusing  on  the  application  environment  of  electronic  compo¬ 
nent  design. 
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The  technical  activities  of  CFI  are  conducted  under  a  single  Technical  Coordinating  Com¬ 
mittee,  chaired  by  CFI’s  Vice-President  of  Technology.  Since  1991,  the  technical  efforts 
have  been  organized  into  two  groups: 

♦  Electronic  Design  Information  Working  Groups:  Design  Representation 
(Library  and  Design  Hierarchy,  Timing/Delay  Data  and  Constraints),  Simula¬ 
tion  Backplane,  Component  Information  Representation  Electronic  Data  Book 
(Dictionary,  Framework,  Scenarios),  Application-Specific  Integrated  Circuit 
(ASIC)  Library  Standard,  Technology  CAD  Device  Modeling  (TCAD  Semi¬ 
conductor  Process  Representation,  TCAD  Semiconductor  Wafer  Representa¬ 
tion). 

•  Domain  Independent  Services  Working  Groups:  Inter-Tool  Communica¬ 
tion,  Tool  Encapsulation  Specification,  Extension  Language,  Task  and  Session 
Management,  Design  Object  Management. 

The  1 990  Integration  Project  featured  the  Design  Representation  Programming  Interface 
(DR  PI)  for  electrical  connectivity  data.  Twenty-two  companies  participated  in  this 
project,  which  was  demonstrated  at  DAC  1990.  The  1991  Integration  Project  focused  on 
the  “framework  cockpit,”  adding  Tool  Encapsulation  Specification  and  Inter-Tool  Com¬ 
munication  functionality  to  the  DR  PI.  It  was  demonstrated  at  DAC  1991. 

The  two  integration  projects  were  basically  proof  of  concept  demonstrations.  CFI  realized 
that  feedback  from  actual  experience  integrating  CAD  tools  was  critical  to  the  efficacy 
and  usability  of  its  standards.  Beginning  in  1992,  the  integration  project  efforts  were 
expanded  to  multiple  pilot  projects  that  would  exercise  the  emerging  CFI  technology  in 
actual  tool  integration  situations.  The  pilot  projects,  like  beta  test  sites,  provide  feedback 
on  critical  issues  (e.g.,  incorrect  or  missing  functionality)  to  the  responsible  CFI  working 
groups.  The  working  groups  use  Quick  Response  Teams  to  address  the  issues  raised  (in 
less  than  one  week,  if  possible).  The  Pilot  Projects  help  assure  a  usable  standard,  while 
accelerating  the  standard  development  process. 

For  Release  1.0,  four  pilot  projects  were  undertaken  in  1992.  The  Hewlett-Packard/ 
Cadence/Mentor  Graphics  project  focused  on  the  Design  Representation  Electrical  Con¬ 
nectivity  information  model  and  programming  interface.  The  Sun  Microsystems  project 
focused  on  Inter-Tool  Communications.  The  EuroCFI  project  (Gesellschaft  fur  Mathema- 
tik  und  Datenverarbeitung  MBH  (GMD),  Cadlab,  Siemens-Nixdorf)  embedded  CFI  tech¬ 
nology  into  the  JESSI  Common  Framework,  focusing  on  the  Inter-Tool  Communications 
programming  interface  and  message  dictionary.  The  IBM  Inter-Framework  Protocol 
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project  used  the  Inter-Tool  Communications  programming  interface.  Tool  Encapsulation 
Specification,  Extension  Language,  and  error  handling  programming  interface  compo¬ 
nents  of  Release  1 .0. 

CFT’s  Standards  for  Electronic  Design  Automation,  Release  1.0  were  published  in  Decem¬ 
ber  1992  in  four  volumes: 

•  Design  Representation  Programming  Interface  Electrical  Connectivity. 

•  Inter-Tool  Communications  Programming  Interface. 

•  Tool  Encapsulation  Specification. 

•  Computing  Environment  Services,  comprising  the  following: 

Base  System  Services  (POSIX,  the  Portable  Operating  System  Interface  for 
Computer  Environments) 

Base  Networking  Services  (X/Open  Transport  Interface 
Basic  User  Interface  (XI 1R4) 

Extension  Language:  Core  Language  Selection  (Scheme,  IEEE  P1178/D5) 
Error  Handling  Programming  Interface. 

Release  2.0,  work  in  progress,  is  targeted  at  the  “front-end  integration”  task,  addressing 
integration  of  front  end  tools  (e.g.,  schematic  capture,  synthesis,  simulation,  and  timing 
analysis)  for  ASIC  and  printed  circuit  board  (PCB)  design.  It  will  include  new  or  extended 
standards  for  design  view  selection,  dynamic  evaluation  of  user  and  design  information 
for  tool  invocation,  expanded  Inter-Tool  Communication  messaging,  and  design  object 
selection  and  access.  Siemens-Nixdorf,  EBM,  and  Hewlett-Packard  have  proposed  Release 
2.0  pilot  projects. 

Release  3.0  will  address  integration  of  back-end  tools  for  physical  design  and  test.  CFI  is 
discussing  linkage  for  Release  3.0  with  PDES,  Inc.  and  PAP-E. 

Technology  Transfer  Approach  and  Plans:  The  primary  means  for  technology  transfer 
from  CFI  is  through  the  direct  participation  of  personnel  from  the  member  companies 
involved  in  the  work.  This  involves  the  working  group  activities  as  well  as  the  pilot 
projects.  CFI  will  work  with  vendors  who  wish  to  brandmark  their  tools  as  CFI  compliant. 
CFI  is  working  on  a  certification  program;  it  hopes  to  have  the  program  in  place  for  the 
Design  Representation  Programming  Interface  during  the  fourth  quarter  of  1993.  This  will 
likely  involve  reference  software  that  demonstrates  a  correct  use  of  each  programming 
interface. 
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Linkages:  CFI  is  endorsing  some  existing  standards,  such  as  POSIX  and  XI 1  for  comput¬ 
ing  environment,  Scheme  for  extension  language,  and  EXPRESS  for  information  model¬ 
ing.  For  the  most  part,  CFI  is  developing  its  own  solutions  to  the  other  needs  and  problems 
which  arise. 

CFI  also  has  links  to  Electronic  Data  Interchange  Format  (EDIF),  PDFS,  Inc.,  PAP-E, 
Object  Management  Group  (OMG)  and  Microelectronics  and  Computer  Technology  Cor¬ 
poration  (MCC). 

Primary  Contacts: 

Andrew  J.  Graham  Don  Cottrell 

President  Vice  President  of  Technology 

CAD  Framework  Initiative,  Inc.  CAD  Framework  Initiative,  Inc. 

4030  West  Braker  Lane,  Suite  550  4030  West  Braker  Lane,  Suite  550 

Austin,  Texas  78759  Austin,  Texas  78759 

(512)  338-3739  (5 1 2)  338-3379 

cottrell@cfi.org 

CFI  also  has  on-line  documentation  available  via  ftp  or  email.  An  empty  email  message, 
where  there  is  not  text  in  the  mail  body,  to  cfi-server@cfi.org  with  subject  “help”  will  get 
a  reply  about  using  the  server. 

Matrix  Notes:  The  entries  are  basically  self-descriptive.  Most  of  the  work  is  self-devel¬ 
oped.  Only  those  pieces  called  out  as  named  standards  are  existing  or  nearly  complete 
standards.  The  following  is  additional  information  on  selected  topics  from  the  matrix. 

•  Exception  Handling  Interface.  An  approach  to  handling  problems  which  arise 
when  data  is  being  moved  around.  Broadly  applicable  to  areas  beyond  the 
immediate  interest  of  CFI. 

•  Tool  Encapsulation  Specification.  An  approach  for  describing  software  tools 
in  a  computer-readable  format.  For  a  general  type  of  tool,  a  set  of  descriptors  is 
devised  which  characterizes  a  specific  example  of  such  a  tool  based  on  a  number 
of  abstract  tool  capabilities  and  characteristics. 

•  Very  High  Speed  Integrated  Circuit  (VHSIC)  Hardware  Design  Language 
(VHDL),  Electronic  Design  Interchange  Format  (EDIF).  Information  mod¬ 
eling  methods/languages  intended  for  integrated  circuit  design. 

•  Scheme.  A  programming  language  derived  from  Lisp. 
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Table  A-4.  CAD  Framework  Initiative,  Inc.  (CFI)  Matrix 


Technical  Categories 

Business  View 

Infonnation  View 

Technology  View 

Integration 

Frameworks  and 
Architectures 

•  Electronic  Design 
Logical  Connectivity 
Model 

•  Prognunming  & 
Database  Subroutine 
Libnuy  based  on 

Dam  Representation 

•  EXPRESS  for 
Infonnation  Model 

Operating  Systems <ind 

Distributed 

Environments 

•  POSIX  Tools 

•  Exception  Hjuidling 
Interface 

•  POSIX 

Communications 

•  Inter-tool 

Communication  Use 
Architecture 

•  Message  Protocol 

•  Prognunmatic 
Subroutine  Library 

•  Programming 
Liuiguage 

•  TCP/IP 

DaUi  Miinagement 
Systems 

•  Storage  Manager 
Interface 

•  Common  Interface  to 
Databc'ise 

•  Configuration 
M^magement 

•  Component 
Interconnect  Rules 
forBuilding  Suindard 
Libraries 

•  Distributed  Files  and 
Data 

•  Unix  File  Systems 

Application 
Development  Tools 
jind  Methods 

•  Tool  Encapsulation 
Specification 

Data  Representations 

•  VHDL 

•  EDIF 

•  VHDL 

•  Electronic  Design 
Information  Model 

Infonnalion  Modeling 
Tools  and  Methods 


User  Interfaces 


•  Style  Guidelines 


XI 1  Underlying 
Standard 


Prognunming  *  Scheme  •  C 

Liinguages  .  C++ 


Security  Tools  and 

•  (Part  of  Database 

Methods 

Management  Work) 
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Title:  Corporation  of  Open  Systems  (COS)  -  Organization 

Scope:  Developing  and  promoting  open  systems  technologies,  in  particular  Open  Systems 
Interconnection  (OSI)  based  communications  profile.  COS  is  also  interested  in  Integrated 
Services  Digital  Network  (ISDN)  efforts.  COS  also  promotes  development  of  conform¬ 
ance  testing  activities  including  the  development  of  test  systems,  test  procedures,  and  har¬ 
monization.  The  organization  is  also  involved  in  several  training  educational  activities 
related  to  open  communications  systems. 

Level  of  Effort:  COS  is  a  consortium  of  about  100  companies,  a  mixture  of  users,  ven¬ 
dors,  and  systems  integrators.  These  include  manufacturing,  process,  and  financial  compa¬ 
nies  on  the  user  side;  and  computer  and  communications  manufacturers  on  the  vendor  and 
systems  integrator  side.  COS  has  a  full  time  staff  of  about  50  people  and  is  located  in 
McLean,  Virginia.  Its  main  funding  comes  from  membership  dues  and  revenue  generated 
by  its  offered  services. 

Performers:  COS  has  done  work  in-house  in  the  training  area  and  in  offering  test  ser¬ 
vices,  but  has  mostly  contracted  with  outside  companies  for  building  test  systems.  Several 
member  companies  have  also  participated  in  technical  areas  of  test  procedure  develop¬ 
ment  and  implementors  agreements. 

Duration:  Ongoing. 

Intent:  To  support  and  promote  technologies  based  on  open  systems  for  communications. 

Description  of  Work  Done;  COS  has  developed  a  “COS  mark”  program  (along  the  lines 
of  a  “seal  of  approval”)  to  assess  conformance  of  products  complying  to  OSI  standards.  It 
has  acquired  conformance  testing  tools  and  are  making  them  available  to  their  members. 
COS  has  developed  training  material  and  offers  conferences  and  workshops  on  open  sys¬ 
tems.  The  members  have  organized  themselves  into  special  interest  groups  (SIGs)  and, 
through  them,  have  developed  the  required  agreements.  There  are  SIGs  for  Manufacturing 
Automation  Protocol/Technical  and  Office  Protocol  (MAP/TOP)  users.  Integrated  Ser¬ 
vices  Digital  Network  (ISDN),  and  testing  policy.  The  Users  Alliance  for  Open  Systems  is 
also  part  of  COS. 

Results:  COS  has  developed  a  procedure  for  the  COS  mark  program.  It  offers  conform¬ 
ance  testing  for  OSI  based  products.  It  has  conducted  and  continues  to  conduct  seminars, 
conferences,  and  workshops  on  open  systems. 
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Technology  Transfer  Approach  and  Plans:  COS  is  making  its  conformance  testing 
tools  and  services  available  to  the  member  companies  and  is  promoting  its  activities 
through  an  education,  awareness,  and  training  program. 

Linkages:  COS  is  linked  to  the  Computer  and  Business  Equipment  Manufacturers  Asso¬ 
ciation  (CBEMA),  the  National  Institute  of  Standards  and  Technology  (NIST),  American 
National  Standards  Institute  (ANSI),  X/Open,  the  MAP/TOP  Users  Group,  and  the  Users 
Alliance  for  Open  Systems. 


Table  A-5.  Corporation  of  Open  Systems  (COS)  Matrix 


Technical  Categories 

Business  View 

Infonnation  View 

Technology  View 

Integration 

Frameworks  md 
Architectures 

•  User  Requests  for 
Open  Systems 

Operating  Systems  iincl 

Distributed 

Environments 

Communications 

•  Strategies  for  OS  I 

•  OSI 

•  OSI 

Daui  M^inagement 
Systems 

Application 
Development  Tools 
and  Methods 

•  Conformance 

Testing 

♦  Policies  & 

Procedures 

•  Education  and 
Awareness  of  OSI 
Testing 

•  Conform;uice 

Testing  Tools 

Dam  Represenmtions 

Information  Modeling 
Tools  imd  Methods 

User  Interfaces 

Program  min  g 

Languages 

Security  Tools  and 
Methods 

Title:  Enterprise  Integration  Program  (EIP)  -  Air  Force  Program 
Scope:  The  EIP  program  is  divided  into  six  phases: 

•  Phase  1  includes  the  following  tasks:  needs  analysis  and  requirements  definition 
for  enterprise  integration  across  industry,  state-of-the-art  assessment  of  technol¬ 
ogies  and  methods  needed  for  enterprise  integration,  enterprise  integration 
guidelines,  core  specifications  for  particular  industry  architectures,  research  and 
development  analysis  and  prioritization,  and  advisory  and  review  board  selec¬ 
tion. 

•  Phase  II  will  include  functional  specification  of  pilot  sites  for  integration, 
research  and  development  of  technologies  identified  as  missing,  education  and 
training  in  the  concepts  of  enterprise  integration  to  industry  and  the  pilot  sites, 
technology  and  product  awareness  within  the  concepts  of  enterprise  integration, 
pilot-site  preparation,  national  consensus  building  on  enterprise  integration 
guidelines,  and  testing  of  enterprise  integration  guideline-compliant  products. 

•  Phase  III  will  implement  and  demonstrate  the  EIP  technologies  in  a  production 
environment  using  pilot  sites,  conduct  advanced  research  and  development,  and 
perform  a  follow-on  assessment  of  enterprise  integration  at  the  pilot  sites. 

•  Phase  IV  will  perform  additional  research  and  development. 

•  Phase  V  will  extend  the  enterprise  integration  guidelines  and  develop  additional 
technology  to  support  additional  standards. 

•  Phase  VI  will  perform  more  implementations. 

Phases  IV,  V,  and  VI  are  optional.  Work  related  to  these  phases  will  be  performed  if 
approved  by  the  U.S.  Air  Force  at  a  later  date. 

Level  of  Effort:  The  total  contract  value  (phases  I  through  VI)  is  on  the  order  of  $58  mil¬ 
lion.  Funding  for  phases  I,  II,  and  III  will  be  about  $23  million. 

Performers:  The  program  sponsor  is  the  U.S.  Air  Force.  SofTech,  Inc.  leads  a  team  com¬ 
posed  of  BDM  International,  Cimflex  Technowledge  Corporation,  Cincinnati  Milacron, 
Dravo  Automation  Systems,  Honeywell,  Industrial  Technology  Institute,  Martin  Marietta, 
McDonnell  Douglas,  Microelectronics  and  Computer  Technology  Corporation  (MCC), 
Price  Waterhouse,  Rensselaer  Polytechnic  Institute,  and  Wizdom  Systems. 

Duration:  EIP  began  April  1,  1991,  and  is  scheduled  to  end  March  31,  1996. 

Intent:  The  EIP  objective  is  to  contribute  to  a  national  initiative  for  information  systems 
integration  for  inter-enterprises  and  intra-enterprises.  EIP  will  accomplish  this  objective 
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by  assisting  in  national  consensus  building;  stimulating  the  development  of  commercial 
products;  and  validating  the  El  framework  and  guidelines  as  well  as  the  core  functional 
specifications  and  related  standards.  EIP  aims  to  bring  about  a  fairly  wide  consensus 
among  industries  and  their  subcontractors  by  focusing  on  the  needs  of  the  wide  spectrum 
of  companies  that  comprise  these  subcontractors  and  using  their  knowledge,  perspectives, 
and  experiences.  Although  EIP  will  stimulate  the  development  of  standards  and  commer¬ 
cial  products  embodying  these  standards,  its  work  is  not  directly  intended  to  lead  to  the 
development  of  new  standards.  Its  support  of  various  standards  efforts,  however,  is 
intended  to  help  lead  to  the  acceptance  of  the.se  standards. 

The  deliverables  of  this  program  are  research  results  in  specific  problem  areas  of  enter¬ 
prise  integration,  a  group  of  industries  that  subscribe  to  the  enterprise  integration  vision, 
products  (from  vendors)  that  solve  parts  of  the  enterprise  integration  problem  and  seam¬ 
lessly  interface  with  other  products,  and  pilot  sites  that  implement  enterprise  integration 
using  these  products. 

Description  of  Work  Done:  The  overall  program  is  in  its  early  stages  and  currently  the 
needs  analysis  and  requirements  task  is  in  progress. 

Results:  None  yet. 

Technology  Transfer  Approach  and  Plans:  EIP  has  a  comprehensive  technology  trans¬ 
fer  plan  which  includes  the  establishment  of  advisory  and  review  boards  to  aid  technology 
transfer,  educate  users,  and  begin  consensus  building  on  enterprise  integration  efforts. 
Technical  experts  from  the  Air  Force  and  industry  will  form  these  boards.  A  Senior  Exec¬ 
utive  Review  Board  will  be  established  to  provide  long-term  strategic  planning  input. 

Conformance  and  performance  testing  of  products  will  be  performed  by  neutral  organiza¬ 
tions  selected  by  the  program.  Appropriate  knowledge  and  information  will  be  transferred 
to  the  testing  organizations. 

Full-scale  pilot  implementation  sites  will  be  chosen  and  established  to  demonstrate  both 
intra-  and  inter-enterprise  integration. 

Education  and  training  programs  wiU  be  established  to  offer  workshops  and  courses  to 
build  public  awareness  in  the  enterprise  integration  strategies  adopted  by  this  program, 
and  provide  in-depth  training  in  the  program’s  core  specifications  and  the  products  and 
technologies  used  in  the  pilot  implementations.  These  training  programs  will  be  geared  to 
a  wide  spectrum  of  management  and  technical  personnel. 
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EIP  will  have  an  advocacy  program  which  will  set  up  and  administer  user  groups.  These 
groups  will  include  academia,  government,  and  industry,  and  will  provide  formalized 
input  to  contractors,  vendors,  and  standards  bodies,  thus  helping  to  establish  a  national 
consensus  for  the  enterprise  integration  guidelines  developed  in  this  program. 

Finally,  a  comprehensive  cost-benefit  analysis  model  will  be  created  to  assess  the  benefits 
of  enterprise  integration  at  the  pilot  sites  and  justify  the  technology  adoption  decisions 
taken  at  these  sites.  Also,  relevant  measurement  criteria  will  be  developed  to  assess  the 
success  of  this  program  in  its  technology  transfer  tasks. 

Linkages:  This  program  will  participate  in  International  Organization  for  Standardization 
(ISO)  committees  and  working  groups  which  are  working  on  integration  guidelines.  Rep¬ 
resentatives  from  such  standards  committees  will  be  invited  to  participate  in  consensus 
building  activities.  Users  groups  established  by  EIP  will  provide  inputs  to  the  relevant 
international  standards  committees. 

Reference:  EIF  contract  led  by  IBM  and  Northrop,  sponsored  by  U.S.  Air  Force  MAN- 
TECH. 

Primary  Contacts: 

Montie  Felman 
Program  Manager 
SofTech,  Inc. 

Fairborn,  Ohio 


Lt.  Todd  Guss 
Air  Force  MANTECH 
Dayton,  Ohio 


Table  A-6.  Enterprise  Integration  Program  (EIP)  Matrix 


Technical  Categories 


Integration 
Fnimeworks  and 
Architectures 


Operating  Systems  <ind 

Distributed 

Environments 


Communications 


Data  Miinagement 
Systems 


Application 
Development  Tools 
<ind  Methods 


Daui  Representations 


Infonnation  Modeling 
Tools  and  Methods 


User  Interface 


Programming 

Languages 


Security  Tools  jmd 
Methods 


Business  View 


Title:  Engineering  Information  System  (EIS)  -  Air  Force  Program 

Level  of  Effort:  Phase  1  -  $14  million;  Phase  2  -  $4  million;  Phase  3  -  $1  million. 

Performers:  Honeywell,  Xerox,  Intermetrics,  Inc.,  CAD  Language  Systems,  Inc., 
McDonnell  Douglas  Electronic  Systems  Company,  Arizona  State  University,  and  TRW. 

Duration:  Phase  1  -  June  1987  to  September  1989;  Phase  2  -  August  1989  to  July  1991; 
Phase  3  -  June  1990  to  September  1991. 

Primary  Milestones:  Completion  of  Phase  1  -  the  EIS  Specifications;  completion  of 
Phase  2  -  the  prototype  system;  completion  of  Phase  3  -  application  demonstrations. 

Intent:  This  project  was  intended  to  develop  a  framework  which  addresses  the  problem  of 
integrating  computer-aided  design/manufacturing/engineering  (CAD/CAM/CAE  or  CAx) 
and  computer-aided  integration  (CIM)  tools.  While  intended  to  be  applicable  to  design  in 
general,  the  initial  effort  was  for  the  design  of  integrated  circuits.  Many  CAx/CIM  tools 
exist,  but  getting  them  to  work  together  has  proven  very  difficult.  The  difficulty  of  trans- 
feiring  information  from  one  tool  to  another  was  and  is  seen  as  a  major  barrier  to  enter¬ 
prise  integration  and  competitive  manufacturing  enterprises.  The  program  was  intended  to 
lead  to  a  design  framework  which  is  widely  accepted  in  the  electronics  industry  in  the 
short  term  and  generally  across  industries  in  the  long  term.  Specifically,  the  initial  focus 
for  candidate  standards  was  on  data  representation  and  interoperability  across  environ¬ 
ments. 

The  original  project  requirements  were  determined  by  an  Institute  for  Defense  Analyses 
(IDA)  team  with  the  help  of  workshops  and  interviews.  The  original  project  objectives 
were  to  develop  a  framework  for  a  system  which  integrates  a  wide  variety  of  CAx  tools 
and  to  demonstrate  a  prototype  version  of  that  framework  on  a  deliberately  mixed  set  of 
computer  hardware  and  software.  The  actual  system  requirements  were  very  detailed  and 
specific,  both  in  short-  and  long-term  goals. 

Definitions: 

•  Engineering  Information  Systems  (EIS).  A  framework  for  integration  based 
on  information  sharing,  providing  the  functions  of  tool  integration,  data 
exchange,  engineering  management  and  control,  information  management,  and 
system  administration. 

•  Electronic  Computer-Aided  Design  (ECAD).  Computer  system  for  assisting 
a  designer  in  the  process  of  creating  the  design  for  an  electronic  component  or 
system. 


Description  of  Work  Done:  EIS  work  comprised  two  parts:  a  framework  (or  integration 
infrastructure)  and  domain-specific  information  models.  The  EIS  program  shows  the 
many  advantages  of  looking  at  the  engineering  environment  problem  in  terms  of  the  two 
parts.  The  framework  technology  is  independent  of  domains  and  is  equally  applicable  to 
many  domains  and  life-cycle  phases.  A  domain-specific  information  model  of  the  engi¬ 
neering  design  process  for  integrated  circuits  was  developed  and  u.sed  to  determine  its 
information  needs.  Thus,  part  of  the  program  was  the  development  of  models  for  ECAD 
and  for  the  administration  of  the  design  system. 

The  EIS  was  entirely  implemented  using  an  object-oriented  approach.  Low-level  tools  and 
methods  were  developed  to  implement  the  ECAD  system.  “Wrappers”  were  used  to  allow 
existing  CAx  tools  to  fit  into  the  system.  Wrappers  are  software  interfaces  which  modify 
the  user  interface  of  existing  software  packages  to  fit  a  model  defined  for  each  type  of  tool 
(CAD  system,  finite  element  analysis,  etc.).  Communications  throughout  the  system  are 
handled  via  messages  between  the  various  system  components. 

Standards  (or  near-standards)  used  for  this  work  include  Integrated  Computer-Aided  Man¬ 
ufacturing  (ICAM)  Definition  Language  (IDEE lx).  Portable  Operating  System  Interface 
for  Computer  Environments  (POSIX),  X-Windows,  EXPRESS,  Motif,  Ada,  and  C.  Major 
pieces  of  the  EIS  work  were  submitted  to  standards  organizations  as  prototype  or  straw- 
man  standards.  The  core  of  the  proposed  new  standards  is  made  up  of  the  common  infor¬ 
mation  model  (via  the  “object  type  standards”  and  the  “common  exchange  format 
standard”)  and  transparent  communication  (“via  protocol  independent  network  interface 
standards”). 

Results:  The  program  team  claims  significant  external  support  and  input  through  the 
workshops  and  reviews  conducted  periodically  during  the  program.  The  program  was  well 
publicized  via  a  widely  distributed  newsletter.  As  yet,  however,  the  results  have  been 
demonstrated  only  in  one  demonstration  site.  No  evidence  exists  of  any  cost  justification 
studies  for  use  of  the  EIS.  No  evidence  exists  of  any  commercialization  efforts  of  results 
of  the  program.  The  team  appears  to  have  concentrated  on  producing  prototype  standards, 
some  of  which  have  been  handed  off  to  standards  organizations.  To  date,  the  primary 
objectives  of  the  EIS  program  seem  to  be  on  track,  having  met  the  basic  objectives 
through  Phase  2.  Phase  3  is  not  yet  complete.  A  prototype  EIS  for  integrated  circuits  was 
generated  in  Phase  2,  with  implementation  in  a  demonstration  site  to  be  undertaken  as  part 
of  Phase  3. 
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Technology  Transfer  Approach  and  Plans:  The  primary  means  for  technology  transfer 
was  through  submission  of  major  pieces  as  prototype  or  strawman  standards  of  the  EIS 
work  to  standards  organizations.  The  core  of  the  proposed  new  standards  is  made  up  of  the 
common  information  model  (via  the  Object  Type  Standards  and  the  common  exchange 
format  standard)  and  transparent  communication  (via  protocol  independent  network  inter¬ 
face  standards).  During  the  project,  a  newsletter  was  widely  distributed  to  keep  a  wide 
variety  of  interested  people  informed.  Future  plans  include  a  variety  of  demonstration 
sites,  including  some  with  different  design  domains  (besides  integrated  circuits). 

Linkages:  The  EIS  program  used  a  few  existing  standards  (see  above),  and  considered 
many  more  in  the  development  process. 

References: 

EIS  Program.  EIS  Specification  Documents.  Three-volume  set:  EIS  Organization  and  Con¬ 
cepts,  EIS  Specifications  and  Guidelines,  and  EIS  Engineering  Information  Model. 

EIS  Program.  EIS  Update,  a  series  of  newsletters  produced  by  the  EIS  project  team  during 
Phases  1  and  2.  Produced  from  July  1988  to  March  1991. 

Linn,  J.  L.  and  R.  I.  Winner.  The  Department  of  Defense  Requirements  for  Engineering 
Information  Systems.  Two-volume  set.  Alexandria,  VA:  Institute  for  Defense  Anal¬ 
yses,  July  1986. 

A  series  of  EIS  Workshops  open  to  people  interested  in  the  EIS  program,  held  January 
1988,  November  1988,  November  1989,  and  March  1991. 

Primary  Contacts: 

Capt.  Nick  Naclerio  Nancy  Giddings, 

former  WRDC  Program  Program  Manager 
Manager  U.S.  Air  Force,  Honeywell  Systems  and 
now  at  DARPA  Research  Center 

3660  Technology  Drive, 

Minneapolis,  MN 
(612)  782-7337 

Matrix  Notes: 

ECAD  Model.  Engineering  information  model  for  ECAD  environment.  Deals  with  both 
the  product  and  the  design  process.  Includes  capabilities  such  as  schematic  capture  and 
placement. 
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Administrative  Model.  Model  of  required  system  underlying  ECAD  Model.  Deals  with 
the  operational  concerns  of  four  identified  participants:  system  implementor,  system 
administrator,  data  administrator,  and  end  user. 

Application  Object  Model.  Set  of  “objects”  which  models  the  engineering  design  appli¬ 
cation. 

Message  architecture.  Defined  approach  to  building  messages  to  be  sent  within  the  ElS. 

Wrappers.  Software  interfaces  which  reside  between  engineering  programs  and  the  user. 
They  provide  a  means  to  ensure  that  different  programs  which  serve  the  same  purpose 
look  essentially  alike  to  the  user. 

Message  primitives.  Define  how  system  messages  should  be  constructed. 

Engineering  Design  Framework.  Structure  in  which  to  place  the  tools  of  engineering 
design. 

Application  Object  Model  (AOM)  Services.  EIS  capabilities  supporting  the  use  and 
maintenance  of  the  AOM. 

ECAD  Tool  Templates.  Templates  for  building  and  integrating  tools  which  support 
ECAD. 

EDIF,  IDEFlx,  VHDL.  Information  modeling  methods  and  languages.  EDIF  and  VHDL 
are  intended  for  integrated  circuit  design. 

Browser.  Tool  for  looking  at  object-oriented  data  base. 

Policies.  Mechani.sm  for  controlling  EIS  and  its  use. 


Table  A-7.  Engineering  Information  System  (EIS)  Matrix 


Technical  Categories 

Business  View 

Information  View 

Technology  View 

Integration 

Frameworks  and 
Architectures 

•  ECAD  Model 

-  Product 

-  Design  Process 

•  Conu-ol  of  Design 
Process 

•  Administrative 

Model 

•  AOM 

•  Policies 

-  Upon  Entry 

-  Upon  Exit 

Operating  Systems  iind 

Distributed 

Environments 

•  POSIX 

Communications 

•  Message 

Architecture 

•  Wrappers 

♦  Message  Primitives 

Data  Management 
Systems 

•  Engineering  Design 
Framework 

•  AOM  Services 

Application 
Development  Tools 
and  Methods 

•  Browser 

Data  Representations 

Information  Modeling 
Tools  jind  Methods 

•  ECAD 

-Schematic  Capture 
-Placement 

•  EDIF 

•  IDEFIX 

•  VHDL 

User  Interface 

•  Common  User 
Interface  by  Function 

•  X-Windows 

•  ECAD  Tool 

Templates 

Prognimming 

Ljuiguages 

1 

Security  Tools  tuid 
Methods 

Title:  Enterprise  Networking  Event  ‘88  International  (ENE  88i)  -  SME  program 

Level  of  Effort:  Total  funding  was  on  the  order  of  $50  million.  Due  to  the  broad  base  of 
contributors  and  sources  of  funds,  higher  specificity  would  be  very  difficult. 

Performers: 

•  Sponsor.  Society  of  Manufacturing  Engineers  (SME). 

♦  Co-sponsors.  Corporation  for  Open  Systems  (COS)  and  the  Manufacturing 
Automation  Protocol/Technical  and  Office  Protocol  (MAP/TOP)  Users  Group 
(MTUG). 

♦  Network  booth  sponsors.  The  users  of  MAP  and  TOP:  Boeing,  TRW,  Deere, 
General  Motors  (GM),  The  USAF/lndustry  Coalition,  Department  of  Trade  and 
Industry  (UK),  ESPRIT. 

•  Contributing  vendors.  AT&T,  Digital  Equipment  Corporation  (DEC),  IBM, 
Allen  Bradley,  Concord,  Retix,  and  others  had  products  ready  for  the  event. 

♦  Related  conformance  testing.  The  Industrial  Technology  Institute  developed, 
supported,  and  operated  systems  for  testing  conformance  to  the  MAP/TOP  3.0 
specifications. 

•  OSI  protocols.  COS  was  responsible  for  some  Open  Systems  Interconnection 
(OSI)  protocols  like  Transport,  File  Transfer  Access  Method  (FTAM)  and  Mes¬ 
sage  Handling  Service  (MHS). 

Duration:  Work  on  the  Event  was  started  in  June  1986.  The  actual  Event  took  place  June 
6-8,  1988. 

Intent:  The  Event  was  organized  to  show  users  that  the  time  had  come  to  implement 
MAP/OSI  networking  and  to  give  vendors  a  vehicle  by  which  they  could  present  and  pro¬ 
mote  their  products.  The  co-sponsors,  COS  and  MTUG,  intended  it  to  be  the  largest  dem¬ 
onstration  ever  of  standards-based  products  interoperating  in  a  real-life,  networked- 
enterprise  configuration. 

The  Event  addressed  data  communications  standardization  and  the  interoperability  of 
complying  products,  intra-  and  inter-company  communications,  and  manufacturing.  It 
offered  a  common  communications  platform  for  developing  and  implementing  distributed 
applications.  It  also  was  the  first  large-scale  demonstration  of  enterprise  integration  via 
networking  in  the  commercial  world. 

The  Event  was  not  intended  to  lead  to  the  development  of  new  standards.  However,  the 
large  amount  of  work  that  went  into  product  development,  testing,  and  ensuring  interoper- 
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ation  led  to  refinements  of  the  standards  by  identifying  ambiguities  and  implementation 
problems.  This  led  to  products  of  better  quality  and  the  acceptance  of  implementations  by 
users. 

The  deliverables  of  the  Event  were: 

•  The  three-day  show,  the  centerpiece  of  the  Event,  in  which  users  and  vendors 
cooperated  to  display  world-wide  connectivity  and  interoperation  using  stan- 
dards-based  products  and  applications  encompassing  functional  areas  of  an 
enterprise  from  order  processing  to  manufacture  and  shipping. 

•  A  forum  for  user-vendor  contact  for  mutual  discussions  and  evaluations  of  each 
other’s  needs,  offerings,  future  plans,  and  commitment  to  enterprise  integration 
and  open  systems. 

•  A  conference  on  open  systems  along  with  workshops  and  tutorials  designed  to 
help  users  understand  OSI,  its  effects  on  industry,  and  strategies  for  migration. 

Description  of  Work  Done:  The  work  done  in  this  project  included  the  following: 

The  development  of  test  tools  and  methods,  especially  conformance  test  systems  for  the 
following  protocols:  Manufacturing  Message  Specification  (MMS),  Network  Manage¬ 
ment  (NM),  Directory  Services,  802.4  CB  MAC,  802.2  Class  3,  Initial  Graphics  Exchange 
Specification  (IGES),  Transport,  FTAM,  MHS. 

The  development  of  applications  using  products  conforming  to  OSI  standards: 

•  The  demonstration  of  enterprise-wide  connectivity  using  OSI  networking  tech¬ 
nology. 

•  The  development  of  methods  for  deploying  large-scale,  “very”  multi-vendor 
networks. 

•  The  development  of  enabling  tools  that  would  help  applications  developers 
integrate  OSI  services. 

•  The  interoperation  of  standards-based  products  and  applications  built  by  differ¬ 
ent  vendors. 

•  Technical  sessions,  workshops,  and  tutorials. 

Results:  Many  manufacturing  users  see  OSI  enterprise-wide  networking  and  open  sys¬ 
tems  as  a  key  technology  for  integration.  Thus,  the  Event  was  seen  by  them  as  an  impor¬ 
tant  launchpad  for  the  acceptance  and  widespread  adoption  of  OSI-based  profiles  such  as 
MAP/TOP. 
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MAP/TOP  3.0  was  the  networking  standard  being  showcased  at  the  Event.  The  Saturn 
plant  at  Spring  Hill,  Tennessee,  exclusively  using  MAP/TOP,  represents  a  site  implemen¬ 
tation  that  uses  some  of  the  products  resulting  from  the  Event. 

Currently,  the  cost  of  implementing  MAP/TOP  networking  solutions  is  higher  than  other 
available  technologies.  Thus,  at  a  departmental  level  it  may  not  be  seen  as  cost  effective. 
At  the  corporate  level,  where  achieving  enterprise  integration  via  multi-vendor  open  net¬ 
works  is  a  long-term  strategic  objective,  cost  is  a  less  important  factor.  Some  independent 
private  cost-benefit  studies  have  been  performed.  Many  have  concluded  that  long-term 
strategic  benefits  can  be  derived  from  investing  in  OS  I  technology. 

The  program  team  strongly  emphasized  vendor  participation.  About  60  companies  partici¬ 
pated.  Most  of  these  vendors  have  MAP/TOP  3.0  compliant  products  in  the  market  today. 
Some  vendors  announced  new  products  at  or  after  the  event.  However,  this  number  was 
fewer  than  was  hoped  for. 

Technology  Transfer  Approach  and  Plans:  The  Event  did  not  have  an  explicit  technol¬ 
ogy  transfer  plan.  However,  the  demonstration,  which  was  the  most  important  and  visible 
part  of  the  Event,  served  as  a  vehicle  for  technology  transfer.  Large  corporations  repre¬ 
senting  both  users  and  vendors  as  well  as  smaller  vendor  companies  participated  in  the 
demonstration. 

A  number  of  committees  were  formed  from  among  the  participating  companies.  These 
were  responsible  for  various  aspects  of  the  preparation  for  the  Event  and  its  execution. 
There  were  a  number  of  “staging  areas”  around  the  country,  each  with  its  team  leader  and 
user-vendor  team.  The  COS  and  ITl  test  committees  were  responsible  for  development 
and  validation  of  the  test  systems  that  would  then  be  used  to  test  vendor  products  for  con¬ 
formance  at  each  staging  area.  There  were  finance,  management,  and  organization  com¬ 
mittees  as  well. 

An  important  technology  transfer  objective  of  the  Event  was  to  build  awareness  among 
users  that  open  systems  are  a  reality  and  the  products  and  tools  to  realize  them  are  quickly 
becoming  available. 

The  conference,  which  offered  technical  sessions,  workshops,  and  seminars  was  another 
important  technology  transfer  vehicle  aimed  at  helping  users  understand  OSl  technology 
and  its  potential  and  formulate  long-term  and  migration  strategies. 

It  was  anticipated  that  after  the  Event,  participating  vendors  would  rapidly  introduce  new 
OSl-based  products  that  would  enable  users  to  realize  true  multi-vendor  interoperation. 
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Although  a  large  number  of  vendors  showed  early  commitment,  not  as  many  of  the  prod¬ 
ucts  anticipated  have  been  released. 

Linkages:  The  Event  concentrated  on  OS  I  and  MAP/TOP  networking  and  did  not  attempt 
to  integrate  and  maintain  compatibility  with  legacy  systems  (like  TCP/IP)  and  older  ver¬ 
sions  of  standards.  There  was  however,  correspondence  and  dialogue  with  U.S.  GOSIP 
and  European  OSI  and  MAP/TOP  efforts.  The  advantage  of  close  contact  with  legacy  sys¬ 
tems  like  TCP/IP  is  that  newer  efforts  can  learn  from  the  pitfalls  such  systems  have 
already  encountered  and  earn  the  following  and  acceptance  of  Transmission  Control  Pro- 
tocol/lntemet  Protocol  (TCP/IP)  users.  Establishment  of  a  working  relationship  with  the 
Internet  Activities  Board  would  have  helped  U.S.  OSI  and  MAP/TOP  efforts  define  an 
acceptable  migration  path  for  existing  users  of  TCP/IP  and  obtain  for  itself  wider  accep¬ 
tance  in  the  long  run. 

Primary  Contact: 

Pat  VanDoren 
ICSI 

P.O.  Box  1488 
Ann  Arbor,  MI  48106 


Table  A-8.  Enterprise  Networking  Event  ‘88  International  (ENE  88i)  Matrix 


Technical  Categories 

Business  View 

Infonnation  View 

Technology  View 

Integration 

•  OS  I  Reference 

Model 

•  Bridges,  Routers,  and 
Application  Layer 

Fnuneworks  and 

•  Allen-Bradley’s 

Gateways 

Architectures 

5-Level  Pynunid 
Model 

Operating  Systems  and 

Distributed 

Environments 


Communications 


•  Proprietary 


•  Relational!  Data 

•  Relational!  Databcise 

Model 

Technology 

Data  Mcinagement 

•  Configuration 

Management: 

Systems 

NIST  Implementors' 
Agreements, 

ENE  Participants' 
Agreements 

Staging  Areas 

•  Conformance/ 
Interoperability  Test 
Tools  and  Methods 

Application 
Development  Tools 
iind  Methods 

•  Application/ 
Development 
Customization 

Toolkits 

•  Systems  Integration 
Tools 

Information  Modeling 
Tools  <uid  Methods 

User  Interfaces 

Prognimming 

Liinguages 

Security  Tools  and 
Methods 

•  Network 
Connectivity 
Diagrams 
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Title:  Federal  Information  Processing  Standards  Publications  (FIPS  Pubs)  - 
National  Institute  of  Standards  and  Technology  (NIST)  Program 

Scope:  Develop  publications  for  U.S.  Government-wide  standards  for  computer  software, 
hardware,  data  management,  networks,  and  security. 

Level  of  Effort:  Only  those  standards  that  promise  sizable  benefits  to  the  U.S.  Govern¬ 
ment  are  issued  as  FIPS. 

Performers:  Voluntary  industry  standards  organizations  work  in  partnership  with  the 
NIST  National  Computer  Systems  Laboratory  (NCSL). 

Duration:  Ongoing  effort. 

Intent:  Goals  of  this  program  are  to: 

•  Improve  the  life-cycle  efficiency  and  effectiveness  of  Federal  information  tech¬ 
nology  resources. 

•  Facilitate  the  competitive  and  economic  procurement  of  systems,  components, 
and  services. 

•  Improve  the  portability  of  data,  software,  and  technical  skills  across  systems. 

•  Protect  systems  and  networks  against  unauthorized  access,  manipulation, 
abuse,  and  protect  information  from  unauthorized  modification  or  disclosure. 

»  Reduce  waste,  errors,  and  unnecessary  duplication  in  the  application  and  use  of 
systems. 

•  Increase  the  productivity  of  the  Federal  workforce. 

Description  of  Work  Done:  Develop  publications,  including  standards,  guidelines,  and 
program  information  documents,  into  the  following  categories: 

•  General  Publications 

•  Hardware  Standards  and  Guidelines 

•  Software  Standards  and  Guidelines 

•  Data  Standards  and  Guidelines 

•  Automated  Data  Processing  (ADP)  Operations  Standards  and  Guidelines 

•  Related  Telecommunications  Standards 

•  Conformance  Tests 
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Results:  FIPS  and  the  specifications  they  adopt  are  implemented  into  computer  products. 

NCSL  sees  a  need  for  expansion  of  its  efforts  in  structuring  conformance  testing  to  these 

FIPS,  and  is  in  the  process  of  fonnulating  a  program. 

Technology  Transfer  Approach  and  Plans:  Several  contributions  have  been  made  in 

this  area.  SGML  and  SQL  are  two  standards  currently  used  by  the  Product  Data  Exchange 

supporting  STEP  (PDES)  activities. 

•  The  Standard  Generalized  Mark-up  Language  (SGML)  was  a  1987  CALS 
deliverable  for  NIST;  a  validation  suite  and  reference  parser  were  developed. 
These  are  both  available  through  NTIS.  The  ANSI  X3V1  committee  currently 
develops  standardized  test  cases  under  the  “conformance  testing  initiative.” 
These  test  cases,  as  they  are  approved,  will  be  publicly  available  as  a  reference 
application  to  test  for  conformance  to  SGML. 

•  The  SQL  test  suite.  Version  2.0,  was  released  in  January  1990.  This  suite  tests 
compliance  with  FIPS  127,  Database  Language  SQL.  Approximately  60  ven¬ 
dors,  integrators,  standards  organizations,  and  certification  agencies  presently 
use  the  SQL  test  suite,  or  its  predecessor.  Version  1.2,  released  May  1989.  A 
commercial  conformance  testing  service  began  at  NIST  in  April  1 990. 

References: 

FIPS  Pubs  are  sold  by  the  National  Technical  Information  Service,  5285  Port  Royal  Road, 

Springfield,  V A  22161. 

National  Technical  Information  Service.  The  SGML  Parser.  Springfield,  VA:  NIST,  1987. 

NTIS  PB  87-  2351 15AVCC. 

National  Technical  Information  Service.  Database  Language  SQL.  Springfield,  VA:  NIST, 

February  2,  1990.  FIPS  Publication  127-1. 


Title:  Institute  of  Electronics  and  Electrical  Engineers  (IEEE),  Inc.  -  Organization 

Scope:  Supporting  development  of  standards  related  to  information  technology. 

Level  of  Effort:  Standard-specific  working  groups  are  sponsored  by  IEEE  with  work 
items  are  picked  by  established  procedures. 

Performers:  The  work  is  done  by  the  working  groups  composed  of  both  IEEE  members 
and  non-members. 

Duration:  Ongoing. 

Intent:  To  develop  standards  and  test  procedures  related  to  information  technology.  The 
standards  are  published  by  IEEE  and,  in  many  cases,  submitted  to  ANSI  or  the  Interna¬ 
tional  Organization  for  Standardization  (ISO)  to  make  them  international  standards. 

Description  of  Work  Done:  The  IEEE  efforts  related  to  information  technology  are  local 
area  networks  (project  802),  operating  systems  (POSIX,  the  Portable  Operating  System 
Interface  for  Computer  Environments),  computer  languages  (Ada,  Pascal,  assembly),  soft¬ 
ware  engineering,  and  terminology  for  simulation. 

Results:  Standards  in  local  area  networks,  languages,  software  engineering,  and  tenninol- 
ogy  for  simulation  exist.  The  work  is  underway  for  POSIX  standards. 


Table  A-9.  Institute  of  Electronics  and  Electrical  Engineers  (IEEE),  Inc.  Matrix 


Technical  Categories  Business  View 


Integration 
Frameworks  md 
Architectures 


Operating  Systems  iind 

Distributed 

Environments 


Communications 


Information  View 


Daui  Mjinagement 
Systems 


Application 
Development  Tools 
cind  Methods 


Dam  Representations 


Information  Modeling 
Tools  iind  Methods 


User  Interface 


Programming 

Languages 


Security  Tools  and 
Methods 


Terminology  for 
Simulation 


Terminology  for 
Simulation 


Local  Area  Networks 
Project  802 

Interface  Stand^u'ds  - 
Futurebus 


SoftWcire 

Engineering 

Suindiu-ds 

Software 
Verification  & 
Validation 

Guide  to  Softwiire 

Configuration 

Management 


•  Recommended 

•  Pasccil 

Practice  for  Ada 

•  Assembly  L^inguage 

•  High-Level 

Languages  for 
Microcomputers 

Title:  Initial  Graphics  Exchange  Specification  (IGES)  -  IPO  Program 

Level  of  Effort:  Primarily  volunteer  effort,  with  some  support  from  the  Department  of 
Defense  Computer-Aided  Logistics  Support  (CALS)  program. 

Performers:  Members  of  the  IGES/PDES  (Product  Data  Exchange  Standard)  Organiza¬ 
tion  (IPO) 

Duration:  Ongoing. 

Primary  Milestones:  Versions  1,  2,  3, 4,  and  5  (completed  in  1990)  of  IGES.  Version  5.1, 
currently  under  development,  is  intended  for  completion  by  the  end  of  1 991 . 

Intent:  IGES  defines  a  neutral  file  format  for  transferring  data  used  to  represent  the  geo¬ 
metric  information  about  a  product.  These  data  are  typically  contained  in  and  generated  by 
a  computer-aided  design  (CAD)  program.  IGES  is  composed  of  a  number  of  “entities” 
representing  low-level  items  that  appear  on  a  drawing. 

Results:  IGES  is  a  widely  used  approach  for  transferring  CAD  data  among  differing  CAD 
systems  and  other  destinations,  such  as  computer-aided  machining  software.  Now  in  its 
fifth  version,  it  has  steadily  grown  in  capability  and  use.  The  largest  problem  with  IGES  is 
that  it  is  so  big  and  complex  (often  capable  of  accomplishing  the  same  purpose  in  more 
than  one  way)  that  different  software  vendor  products  often  are  unsuccessful  in  transfer¬ 
ring  information  using  IGES.  Therefore,  IGES  has  generally  been  considered  to  be  diffi¬ 
cult  to  use  and  far  from  perfect. 

Current  activities  in  the  IPO  are  aimed  at  correcting  this  problem  of  a  general  lack  of  focus 
by  adopting  the  concept  of  application  protocols.  An  application  protocol  (AP)  is  com¬ 
posed  of  a  concept  that  needs  to  be  transferred  from  one  system  to  another  and  the  individ¬ 
ual  entities  required  to  make  that  transfer.  The  difference  between  a  traditional  IGES 
transfer  and  an  AP  transfer  is  that  a  traditional  transfer  is  made  up  of  a  set  of  IGES  enti¬ 
ties,  while  for  an  AP  transfer  the  “entity”  being  transferred  is  a  concept  or  idea,  with  what¬ 
ever  entities  are  necessary  to  embody  the  concept.  Because  of  the  much  tighter  definitions 
included  in  the  AP,  the  transfer  should  be  much  less  prone  to  problems  and  misunder¬ 
standings. 

Technology  Transfer  Approach  and  Plans:  Numerous  CAD,  computer-assisted 
machining,  and  related  software  packages  supporting  IGES  are  already  available.  The 
CALS  program  has  established  a  CALS  Shared  Resource  Center  (CSRC)  Metalworking 
Technology,  Inc.,  in  Johnstown,  Pennsylvania,  to  assist  small  DoD  suppliers  in  adopting 
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CALS  standards  and  technologies.  Since  IGES  is  one  of  the  CALS  technologies,  the 
CSRC  will  serve  as  an  avenue  for  IGES  technology  transfer. 

Reference: 

National  Computer  Graphics  Association.  IGESfPDES  Organization  Reference  Manual. 
July  1991. 

Primary  Contacts: 


William  Conroy,  Chair 
IGES/PDES  Organization 
EDS  (on  loan  to  NIST) 
(301)  975-3981 


J.C.  Kelly 

IGES  Project  Manager 
IGES/PDES  Organization 
Sandia  National 
Laboratories 
(505)  844-1835 


Table  A-10.  Initial  Graphics  Exchange  Specification  (IGES)  Matrix 


Technical  Categories 

Business  View 

Information  View 

Technology  View 

Integration 

Fniineworks  ?ind 
Architectures 

•  Application 

Protocols 

•  Application 

Protocols 

Operating  Systems  Jind 

Distributed 

Environments 

Communications 

•  Neutral  File  Fonnat 

DaUi  Mjtnagement 
Systems 

Application 
Development  Tools 
cind  Methods 

Daui  Represenuitions 

•  List  of  entities  with 
attributes 

Information  Modeling 
Tools  cuid  Methods 

User  Interface 

Programming 

Liuiguages 

Security  Tools  and 
Methods 
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Title:  Integrated  Information  Support  System  (IISS)  -  Air  Force  Program 

Scope:  IISS  is  a  U.S.  Air  Force  project  to  implement  a  version  of  the  Common  Data 
Model  (CDM).  CDM  is  a  three-schema  architecture  for  distributed  heterogeneous  data¬ 
base  systems.  IISS  is  not  a  general  engineering  information  program  but  intended  to  pro¬ 
duce  database  systems  which  could  be  easily  used  in  an  engineering  information  project. 

Level  of  Effort:  IISS  is  an  ongoing  effort  which  to  date  has  cost  $50  million  over  12 
years. 

Performers: 

•  Control  Data.  Overall  CDM  design  and  implementation,  IISS  integration  and 
test,  and  technology  transfer. 

•  D.  Appleton  Company.  CDM  software  information  services  and  IDEFIX 
methods. 

•  ONTEK.  Defining  and  testing  a  reference  integrated  system. 

•  Simpact  Corporation.  Communication  development 

•  Structural  Dynamics  Research  Corporation.  User  Interface,  Virtual  Termi¬ 
nal,  and  Network  Transaction  Manager. 

•  Arizona  State  University.  Test-bed  operations  and  support. 

Duration:  Begun  in  1978,  its  major  parts  are  completed.  Some  work  is  still  in  progress. 

Intent:  IISS  was  one  of  the  first  efforts  to  build  large  scale  integrated  information  sys¬ 
tems.  The  goal  was  to  implement  a  system  based  on  the  then  new  Three  Schema  Architec¬ 
ture  for  databases  and  show  its  applicability  to  the  problems  associated  with 
manufacturing  large  weapon  systems.  This  effort  promotes  enterprise  integration  by  dem¬ 
onstrating  the  feasibility  of  large  three  schema  databases. 

The  project  was  restricted  to  developing  large  distributed  heterogeneous  databases  so  they 
complied  with  the  standards  (e.g.,  SQL)  existing  at  the  time  for  databases.  Other  compo¬ 
nents  of  the  IISS  system  are  proprietary  although  efforts  are  currently  underway  to  explore 
porting  IISS  to  make  better  use  of  industry  standards  in  the  area  of  communication  and 
database  access  by  using  Open  Systems  Interconnection  (OSI)  and  Remote  Database 
Access  (RDA). 

The  major  deliverable  for  this  project  was  an  integrated  database  which  ran  under  IBM 
and  Digital  Equipment  Corporation  (DEC)  hardware.  Currently,  Intel  is  working  on  a  sys¬ 
tem  running  Unix  to  add  to  DSS. 
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Description  of  Work  Done:  A  prototype  Three  Schema  Architecture  database  system  has 
been  developed.  It  currently  runs  under  VAX/VMS  and  IBM  MVS.  To  implement  this 
system,  IISS  developed  a  data  definition  language  called  Neutral  Data  Definition  Lan¬ 
guage  (NDDL)  used  to  produce  a  data  dictionary  called  the  Common  Data  Model  (CDM). 
Access  to  the  CDM  is  provided  by  the  Neutral  Data  Manipulation  Language  (NDML). 

At  compile  time,  a  precompiler  scans  the  source  for  NDML  statements.  When  one  is 
found,  the  precompiler  replaces  it  with  a  subroutine  call.  It  then  generates  a  subroutine 
which  sends  messages  to  the  machines  which  hold  the  actual  data.  The  messages  contain 
SQL  commands  which  are  executed  at  the  remote  machine  and  then  returns  results. 

Results:  As  one  of  the  first  three-schema  databases,  the  project  produced  important 
results.  Although  not  in  general  use,  IISS  has  had  a  major  impact  on  current  efforts  in 
enterprise  integration.  IISS  concepts  and  approaches  played  a  role  in  the  current  Air  Force 
Enterprise  Integration  Program. 

Technology  Transfer  Approach:  At  this  time  there  is  little  effort  going  on  regarding 
technology  transfer.  There  was  a  major  demonstration  of  a  fully  operational  prototype  at 
Arizona  State  University  in  1987.  Currently,  a  version  of  IISS  is  running  at  the  U.S.  Air 
Force  MANTECH  labs  at  Wright  Patterson  AFB,  Ohio. 

Linkages:  Currently  there  is  little  linkage  from  IISS  to  other  standards  work.  This  may 
change  as  the  Air  Force  is  considering  porting  it  to  standard-based  applications. 

Primary  Contact: 

Dave  Judson 
Phone:  (513)  255-7371 
Fax:  (513)  476-4420 

Matrix  Notes: 

•  CDM.  A  data  dictionary  used  to  implement  a  three-schema  architecture.  It  has 
a  Definitions  Model  for  External  Schemas,  a  Meta  Model  to  represent  Concep¬ 
tual  Schemas,  and  a  Data  Model  to  represent  Internal  Schemas.  CDM  also  sup¬ 
ports  CDM  Administrative  Procedures  to  facilitate  easy  construction  of  data 
models.  A  CDM  Toolkit  is  also  provided  to  compile  programs,  generate  reports, 
and  other  support  functions. 

•  NDDL.  The  language  used  by  CDM  builders  and  administrators  to  build  and 
maintain  IISS  data 

•  NDML.  The  language  used  to  access  the  CDM  and  associated  databases. 
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NTM  (Network  Transaction  Manager).  A  facility  used  to  provide  interpro¬ 
cess  communication  both  within  a  processor  and  to  remote  machines.  It  trans¬ 
ports  database  access  commands  and  keeps  track  of  where  a  process  should 
reside. 


Table  A-11.  Integrated  Information  Support  System  (IISS)  Matrix 


Technical  Categories 

Business  View 

Infonnation  View 

Technology  View 

Integration 

Frameworks  and 
Architectures 

•  CDM  Definitions 

•  CDM  Meta  Model 

•  CDM  Data  Model 

Operating  Systems  Jind 

Distributed 

Environments 

•  VMS 

•  MVS 

•  Unix 

Communications 

•  GOSIPl.O 

•  DECNET 

•  SNA 

Data  Management 
Systems 

•  Entity  Attribute 

•  IRDS 

• 

Application 
Development  Tools 
and  Methods 

•  CDM  Toolkit 

Utilities 
-Report  Writer 
-Translators 
-Comparison 

•  CDM 

Administrative 

Procedures 

•  NTM 

•  Configuration 
Management: 

IISS  Code  Manager 
NTM 

Data  Representations 

• 

Infonnation  Modeling 
Tools  iind  Methods 

•  IDEFIX 

•  IDEFIX 

User  Interface 

•  NDDL  Forms 

Programming 

Languages 

•  NDDL 

•  NDML 

•  SQL 

•  Cobol 

•  Fortnin 

•  C 

Security  Tools  tind 
Methods 

•  Access  Control 

Based  on  User  Role 
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Title:  Information  Resource  Dictionary  System  (IRDS)  -  ANSI  Program 
Level  of  Effort:  Volunteer  effort  by  interested  parties. 

Performers:  International  Organization  for  Standardization  (ISO)  JTCl  SC21/WG3  and 
American  National  Institute  (ANSI)  X3H4. 

Duration:  1 980  through  present. 

Intent:  The  IRDS  Standards  began  as  two  parallel  efforts  in  1980.  The  goals  of  both  the 
ANSI  and  NIST  efforts  were  to  develop  data  dictionary  standards  for  the  description,  con¬ 
trol,  and  management  of  information.  By  developing  these  standards  data  dictionaries, 
computer-aided  .software  engineering  (CASE)  tools  would  be  able  to  share  infonnation.  In 
1983  the  two  efforts  merged  under  the  name  IRDS  with  the  ANSI  technical  committee 
adopting  the  National  Institute  of  Standards  and  Technology  (NIST)  draft  standard.  In 
1985  the  United  States  presented  the  IRDS  proposal  (IRDSl)  to  ISO.  ANSI  and  ISO  ver¬ 
sions  of  IRDS  1  have  continued  to  evolve  and  the  standards  efforts  have  been  expanded  to 
encompass  the  entire  data  repository  and  the  programming  interface. 

The  IRDS  1  Standards  efforts  intended  to  provide  the  builders  and  users  of  enterprise  inte¬ 
gration  information  frameworks  facilities  to  create,  maintain,  and  access  an  Information 
Resource  Dictionary  (IRD)  and  the  associated  IRD  definitions.  Examples  of  the  informa¬ 
tion  that  may  be  captured  in  the  IRD  include: 

•  Data  needed  by  the  enterprise, 

•  Process  information  for  manipulating  the  enterprise  data, 

•  Physical  resource  information  for  processing  the  enterprise  data, 

•  Human  resource  information. 

The  IRDS  1  Standard  is  not  intended  to  provide  a  standard  definition  of  any  information. 
Instead  the  Standard  will  provide  a  framework  that  can  be  used  to  define  the  information 
which  will  be  captured  in  and  maintained  by  an  IRD. 

The  IRDSl  Framework  is  used  to  identify  the  enterprise  data,  hardware,  interfaces,  and 
the  services  provided  by  the  enterprise  processing  facilities.  Data  interchange  formats  and 
data  modeling  schemes  are  examples  of  the  types  of  information  that  may  be  described  by 
the  framework. 

In  1992,  ANSI  and  ISO  agreed  to  evolve  the  IRDS  1  standards  by  incorporating  object-ori¬ 
ented  concepts.  The  vision  of  an  IRDS  composed  of  distributed  repository  objects  provid¬ 
ing  IRDS  services  through  object-oriented,  application  programming  interfaces  is  referred 
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to  as  IRDS2.  An  IRDS2  repository  will  provide  object  management  services,  database 
management  services,  database  access  facilities,  data  modeling  facilities,  CASE  support 
facilities,  dictionary  facilities,  encyclopedia  facilities,  glossary  facilities,  and  thesaurus 
facilities. 

Definitions: 

IRDSl: 

•  Database.  A  collection  of  interrelated  data  stored  together  with  controlled 
redundancy  according  to  a  schema  to  serve  one  or  more  applications. 

•  Database  integrity.  The  consistency  of  a  collection  of  data  in  a  database. 

•  Export.  The  function  of  extracting  information  from  an  IRDS  and  packaging  it 
to  an  export/import  file. 

•  Import.  The  function  of  receiving  data  from  an  export/import  file  into  an  IRDS. 

•  IRD.  Part  of  a  repository  managed  by  an  IRDS  in  which  the  information 
resources  of  an  enterprise  may  be  recorded. 

•  Value.  An  abstraction  with  a  single  characteristic  that  can  be  compared  with 
other  values  and  may  be  encoded. 

•  Data  modeling  facility.  A  set  of  data  structuring  rules  and  an  associated  set  of 
data  manipulation  rules. 

•  Application  schema.  A  set  of  definitions  that  control  what  may  exist  at  any 
time  in  an  application. 

IRDS2: 


•  Application  programming  interface  (API).  A  set  of  functions  that  provide  the 
complete  interface  required  by  an  application  for  obtaining  services  from  a  tool 
or  facility. 

•  Behavior.  The  observable  effects  of  an  object  performing  the  requested  opera¬ 
tion,  including  its  results. 

•  Content  module.  A  specification,  for  a  particular  universe  of  discourse,  of  a  set 
of  object  types  including  the  rules  governing  the  interaction  and  behavior  of 
objects  of  these  types,  and  optionally  one  or  more  instances  of  these  types. 

•  Core  object  model.  The  specification  of  the  behavior  of  the  root  object  type. 
All  other  object  types  inherit  properties,  operations,  and  integrity  rules  from  the 
root  object  type. 
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•  Facility.  An  implementation  of  a  content  module  with  methods  to  support  all 
operations  defined  by  the  content  module’s  object  types  and  the  capability  to 
store  the  module’s  persistent  objects. 

•  IRDS  base  services.  That  set  of  services  that  are  inherent  to  IRDS  systems,  for 
example,  naming,  versioning,  and  object  life  cycle  services. 

•  IRDS  kernel.  The  combination  of  the  core  object  model,  its  underlying  defin¬ 
ing  and  normative  schemas,  and  the  set  of  base  services  inherent  to  IRDS  sys¬ 
tems. 

•  IRDS  service  profiles.  Content  modules  whose  subject  area  is  some  aspect  of 
the  IRDS  system  as  a  universe  of  discourse. 

•  Object  type.  A  specification  of  properties  (attributes  and  relationships),  opera¬ 
tions  which  define  the  behavior  of  objects  of  that  type  and  integrity  rules  that 
apply  to  those  objects. 

•  Root  object  type.  The  object  type  that  packages  primitive  properties,  opera¬ 
tions,  and  integrity  rules  that  must  be  used  as  the  basis  for  all  other  object  types. 

•  Service.  A  related  set  of  operations  that  are  invoked  through  the  interfaces  for 
one  or  more  object  types  in  response  to  requests  or  detected  conditions. 

Description  of  Work  Done:  IRDSl  is  a  data  dictionary  standard  developed  in  parallel  by 
both  ISO  (JTCl  SC21AVG3)  and  ANSI  (X3H4).  The  ANSI  IRDS  standard  is  based  on  the 
entity-relationship  (ER)  model  and  would  be  applicable  to  both  the  NDL  and  SQL  data¬ 
base  languages.  The  ER  data  model  is  fully  extensible  and  captures  both  meta  and  meta- 
meta  data.  The  ISO  IRDS  standard  uses  a  relational  model  for  data  capture.  However,  the 
ISO  standard  is  also  based  on  ISO  SQL. 

The  ISO  IRDS  Framework  (ISO  10027)  provides  a  common  basis  for  developing  infor¬ 
mation  resource  dictionaries  (IRDs)  which  are  sharable  repositories  for  the  definition  of 
the  information  relevant  to  all  or  part  of  an  enterprise. 

There  is  an  ISO  proposal  for  a  Command  Language  and  Panel  Interface  (DP  8800-1, 
March  1987).  However  this  project  has  been  suspended  until  the  Committee  Draft  of 
IRDS  Service  Interface  (CD  10728)  reaches  Draft  International  Standard  (DIS)  status. 
There  are  working  drafts  of  the  IRDS  Design  Support  for  SQL  Applications  and  IRDS 
Export/Import. 

The  Accredited  Standards  Committee  X3,  Information  Processing  Systems,  has  plans  for 
the  development  of  an  IRDS  Extensions  to  Support  CASE  Environments  for  the  Informa¬ 
tion  Exchange  standard.  In  planning  the  evolution  of  the  IRDS  standards,  ANSI  and  ISO 


A-52 


have  been  influenced  by  the  NIST  Reference  Model  for  Frameworks  of  Software  Engi¬ 
neering  Environments,  and  by  the  work  of  the  Object  Management  Group. 

IRDS2  will  be  based  on  an  object  model,  and  will  use  an  Object  Query  Language  with  a 
“select-from-where”  clause  (possible  SQL3)  for  selecting  a  set  of  objects  for  retrieval.  A 
core  object  model  will  support  the  definition  of  generic  base  services  that  together  form 
the  kernel  of  the  IRDS  system.  That  kernel  will  support  implementation  of  IRDS  service 
profiles  and  content  modules  that  represent  the  models  for  the  information  the  IRDS  con¬ 
tains.  Together,  the  set  of  content  modules  for  an  IRDS  system  define  the  information 
model  for  an  enterprise. 

X3H4  has  proposed  changes  to  the  ISO  IRDS  Standard  (IS  10728)  to  introduce  some 
object-oriented  concepts,  including  extensible  operations  and  multiple  inheritance.  X3H4 
technical  reports  under  preparation  include  Repository  Context  Reference  Model  Techni¬ 
cal  Report  and  Repository  Services  Architecture  Technical  Report.  ANSI  and  ISO  are 
working  to  revise  the  ISO  IRDS  Framework  Standard  (IS  10027)  to  include  the  concepts 
of  IRDS2. 

Results:  The  ANSI  draft  IRDS  standard,  X3. 138- 1988,  was  adopted  by  the  U.S.  Govern¬ 
ment  as  FIPS- 156  (Federal  Information  Processing  Standard)  in  1989.  In  this  standard,  a 
command  language  interface,  an  abstract  panel  interface,  and  an  IRD-IRD  data  exchange 
format  were  all  specified.  An  upgrade  to  FIPS-156  is  not  expected  until  1995.  The  U.S. 
Government  has  mandated  that  all  data  dictionaries  used  by  the  government  comply  with 
ANSI  IRDS. 

X3H4  is  working  with  ISO  to  develop  IRDS2  which  will  provide  an  object-oriented  user 
interface  and  complete  data  repository  facilities.  The  proposed  revision  to  the  ISO  IRDS 
Standard  (IS  10728)  reached  CD  status  in  June,  1993. 

Linkages:  ANSI,  ISO,  NIST,  Object  Management  Group  (OMG) 

References: 

Beyer,  H.  et.  al.  A  Comparison  Analysis  of  Repository  Approaches.  September  1990. 

Jones,  Mark  R.  “Evolution  of  Repository  Technology,”  Database  Programming  and 
Design,  April  1992. 

Lewis,  Geoffrey.  “CASE  Integration  Frameworks,”  SunWorld,  July  1991. 

National  Institute  of  Standards  and  Technology.  Reference  Model  for  Frameworks  of  Soft¬ 
ware  Engineering  Environments.  December  1991.  NIST  SP  500-201. 
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Object  Management  Group.  The  Common  Object  Request  Broker:  Architecture  and  Spec¬ 
ification  (CORBA).  Revision  1.1.  December  1991.  OMG  Document  91.12.1. 

Object  Management  Group.  Object  Services  Architecture.  Revision  6.0.  August  1992. 
OMG  Document  92.8.4. 

Object  Management  Group.  Object  Management  Architecture  Guide.  Revision  2.0.  Sep¬ 
tember  1992.  OMG  Document  92.1 1.1. 


Table  A- 12.  Information  Resource  Dictionary  System  (IRDS)  Matrix 


Technical  Categories 

Business  View 

Information  View 

Technology  View 

Integration 

Fnimeworks  and 
Architectures 

•  IRDS  1 

-  ER  Models 
Relational 

•  IRDS  2 

-  Object  Oriented 

•  RDBMS 

•  OODBMS 

Communications 

Operating  Systems  Jind 

Distributed 

Environments 

•  OSFDCE 

•  OMG  CORBA 

Data  Mcinagement 
Systems 

•  Relational 

•  Object  Oriented 

♦  RDBMS 

♦  OODBMS 

♦  SQL 

Application 
Development  Tools 
and  Methods 

•  Extensions  to  CASE 
Environments 

Dam  Represenmtions 

•  Nmning  Conventions 

•  Resources 

•  Dam  modeling 
schemes 

•  Dam  interchimge 
formats 

Information  Modeling 
Tools  and  Methods 

User  Interface 

Prognunming 

Ltuiguages 

Security  Tools  and 
Methods 
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Title:  Manufacturing  Automation  Protocol/Technical  and  Office  Protocol  (MAP/ 
TOP)  Users  Group  -  Society  of  Manufacturing  Engineers  (SME)  Program 

Performers:  MAP/TOP  Users  Group.  The  MAP  effort  was  spearheaded  by  General 
Motors  while  Boeing  took  the  major  initiative  in  progressing  TOP.  Today  the  MAP/TOP 
Users  group  is  administered  by  the  Corporation  of  Open  Systems  (COS)  and  includes 
many  large  corporations,  their  suppliers,  and  others  concerned  with  factory  and  office 
automation. 

Duration:  The  MAP/TOP  effort  started  in  the  early  1980s.  Currently,  both  MAP  and  TOP 
are  in  their  third  versions.  The  Users  Group  is  active  and  has  regular  meetings  with  the 
main  focus  being  testing,  international  harmonization,  and  presenting  a  unified  front  to 
vendors  of  MAP  and  TOP-based  products. 

Primary  Milestones:  MAP  Version  1.0  appeared  in  1984.  Version  2.0,  which  added  a  lot 
of  functionality  to  the  upper  layers,  was  released  in  1985.  March  1985  saw  the  release  of 
Version  2.1  which  included  FT AM.  The  MAP  Enhanced  Performance  Architecture  (EPA) 
was  released  in  1 986.  The  EPA  is  a  three-layer  version  of  MAP  meant  for  specialized  real¬ 
time  needs. 

TOP  Version  1.0  was  released  in  November  1985.  Both  TOP  1.0  and  MAP  2.1  were  fro¬ 
zen  for  a  period  of  time  to  make  changes  to  the  profiles  and  remove  errors  in  their  specifi¬ 
cation.  MAP  and  TOP  versions  3.0  were  released  in  1987,  and  represented  major  upgrades 
from  their  previous  versions. 

An  important  milestone  for  both  MAP  and  TOP  was  the  Enterprise  Networking  Event  ‘88 
International  (see  information  on  ENE  88i  in  this  report)  which  demonstrated  interopera¬ 
bility  of  MAP  and  TOP  products  from  different  vendors  in  a  real-life,  network-enterprise 
configuration. 

Intent:  The  Manufacturing  Automation  Protocol  was  established  to  define  a  local  area 
network  for  terminals,  computing  resources,  and  programmable  devices  within  a  plant  or  a 
complex.  Though  intended  for  local  area  networks  (LANs),  the  architecture  supports  wide 
area  network  interconnection. 

Description  of  Work  Done: 

MAP.  MAP  comprises  12  Open  Systems  Interconnection  (OSI)  protocols  covering  the  7 
layers  of  the  OSI  Reference  Model.  Additionally,  there  is  a  “stream-lined”  model  called 
the  Enhanced  Performance  Architecture  (EPA)  that  operates  over  just  three  layers:  Physi- 
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cal,  Datalink,  and  Application.  The  EPA  is  targeted  for  applications  that  require  rapid 
response  times  and  are  very  fault  tolerant. 

As  the  names  states,  MAP  is  intended  for  manufacturing.  Consequently,  the  selection  of 
the  protocols  correspond  to  those  appropriate  to  the  factory  floor.  Where  this  difference 
becomes  critical  is  in  the  selection  of  the  Physical  Layer  protocol  and  one  of  the  Applica¬ 
tion  layer  protocols. 

For  the  physical  layer,  MAP  has  selected  the  IEEE  802.4  (ISO  8802/4)  Broadband  and 
Carrierband  technology.  This  technology  allows  multiple  channels  over  a  single  physical 
medium.  One  could  run  up  to  six  disparate  MAP  networks  over  a  single  cable.  But  more 
importantly,  one  can  simultaneously  run  non-MAP  networks  over  the  same  MAP  back¬ 
bone.  The  broadband  will  support  voice,  video.  Integrated  Services  Digital  Network 
(ISDN),  Ethernet,  etc. 

In  addition  to  its  multi-services,  multi-protocol,  multiLAN  support,  broadband  cable  is 
well-suited  to  the  factory  floor  due  to  its  low-loss  characteristics  and  its  ability  to  provide 
shielding  from  electrical  and  magnetic  interference.  Broadband  obviates  the  need  for  later 
upgrades. 

MAP  recommends  carrierband  technology  for  single-channel,  shorter  networks  (about 
700  to  1000  meters  between  communicating  stations)  with  fewer  nodes  (32  per  segment). 
Examples  of  appropriate  applications  would  be  control  or  supervisory  subnetworks. 

At  the  Application  layer,  MAP  specifies  six  protocols: 

•  ACSE  (Association  Control  Service  Element) 

•  ROSE  (Remote  Operation  Service  Element) 

•  FTAM  (File  Transfer,  Access,  and  Management) 

•  Directory  Services 

•  Network  Management 

•  MMS  (Manufacturing  Message  Specification) 

MMS  is  a  protocol  very  rich  in  services  and  complexity.  Though  it  is  applicable  to  a  wide 
range  of  factory-floor  applications,  MMS  does  not  describe  application-specific  informa¬ 
tion.  That  job  falls  under  the  charter  of  four  companion  standards  organizations.  Compan¬ 
ion  standards  contain  the  semantics  of  the  factory-floor  device.  The  devices,  along  with 
their  responsible  organizations,  are  Numerical  Control  Devices  (Electronics  Industry 
Association  (EIA)),  Programmable  Controllers  (National  Equipment  Manufacturers  Asso- 
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ciation  (NEMA)),  Robot  Controllers  (Robot  Institute  of  America  (RIA)),  and  Process 
Control  Systems  (Instrument  Society  of  America  (ISA)). 

In  the  long  view  of  enterprise  integration,  MAP  should  be  coupled  with  TOP  (described 
below).  Together  they  address  the  most  of  the  network  communications  problems  of  a 
CIM  enterprise. 

TOP-  The  TOP  profile  addresses  the  communication  networking  requirements  for  com¬ 
mercial,  engineering,  and  government  implementations.  The  TOP  effort  recognizes  the 
need  for  enterprises  to  reduce  costs  and  yet  increase  quality.  Open  systems  in  this  infor¬ 
mation  age  are  one  way  to  accomplish  this.  To  reduce  risk  and  expedite  adoption,  it  speci¬ 
fies  from  the  internationally  recognized  body  of  standards  defined  by  OSI.  Furthermore, 
in  the  interest  of  portability,  it  specifies  application  programming  interfaces. 

The  TOP  program  has  three  basic  goals: 

•  To  promote  the  design,  development  and  testing  of  TOP  products. 

•  To  act  as  a  procurement  tool  for  users. 

•  To  educate  users. 

The  fact  that  MAP  and  TOP  complement  each  other  is  no  accident.  They  were  designed 
from  the  beginning  to  both  work  in  the  enterprise.  TOP  specifically  addresses  the  method 
of  interconnection  to  MAP  networks  in  its  specification. 

TOP  employs  the  common  (and  inexpensive,  relative  to  MAP)  IEEE  802.3  Carrier  Sense 
Multiple  Access/Collision  Detection  (CSMA/CD)  technology  at  its  lower  layers.  This 
technology  is  easy  to  install  and  maintain.  TOP  also  allows  IEEE  802.5  Token  Ring 
because  of  the  popularity  that  low-level  protocol  enjoys  and  X.25  for  wide  area  network 
(WAN)  connectivity. 

The  real  richness  of  TOP  comes  in  its  selection  of  Application  layer  protocols.  These 
include: 

•  X.400  Message  Handling  Services  (Electronic  Mail) 

•  Product  Definition  Interchange  Format  (using  Initial  Graphics  Exchange  Spec¬ 
ification  (IGES)) 

•  Office  Document  Interchange  Format  (using  ODA) 

•  Computer  Graphics  Metafile  Interchange  Format  (using  Graphical  Kemal  Sys¬ 
tem  (GKS)  and  Computer  Graphics  Metafile  (CGM)) 

•  File  Transfer,  Access  and  Management  (FTAM) 


A-58 


•  Virtual  Terminal  (VT) 

•  Directory  Services  (DIS  9594) 

•  Network  Management  (ISO  DP  9596) 

TOP  plans  to  accept  other  standards  as  they  become  mature  while  providing  backward 
compatibility.  Examples  would  include  the  Fiber  Data  Digital  Interface  (FDDI),  ISDN, 
Product  Data  Exchange  Specification  (PDFS),  Computer  Graphics  Interface  (CGI),  Dis¬ 
tributed  Transaction  Processing,  Remote  Database  Access  (RDA),  and  Electronic  Data 
Interchange  (EDI)  (as  transferred  by  X.400). 

TOP  integrates  the  engineering  and  office  LANs  by  intent.  By  the  use  of  a  lower-layer 
bridge  (802.3  to  802.4),  one  can  interconnect  with  the  MAP  factory  floor  nets  and  enjoy 
total  enterprise  integration. 

Technology  Transfer  Approach  and  Plans:  Technology  transfer  is  mainly  through  the 
MAP/TOP  Users  Group  and  trade  shows  like  Autofact.  Conformance  testing  is  another 
important  means  of  transferring  technology.  SME  (Society  of  Manufacturing  Engineers) 
offers  MAP/TOP  training. 

Linkages:  MAP/TOP  has  strong  links  to  the  International  Organization  for  Standardiza¬ 
tion  (ISO)  because  most  of  the  standards  it  uses  are  ISO  standards.  There  are  links  to  IEEE 
for  similar  reasons  (lower-layer  protocols).  SME  and  COS  are  other  organizations  to 
which  MAP  and  TOP  have  strong  ties. 


Table  A- 13.  Manufacturing  Automation  Protocol/Technical 

(MAP/TOP)  Matrix 


Technical  Categories 


Integration 
Fnuneworks  and 
Architectures 


Operating  Systems  md 

Distributed 

Environments 


Application 
Development  Tools 
and  Methods 


Data  Representations 


Information  Modeling 
Tools  and  Methods 


User  Interfaces 


Programming 

Languages 


Security  Tools  jmd 
Methods 


Business  View 


Infonnation  View 


and  Office  Protocol 


Technology  View 


OSI  Reference 
Model 


Network 

Management 

Applications 

Directory  Server 
Applications 


OSI  Protocols:  MHS, 
FTAM,  MMS,  NM. 
DS,  ASCE, 
SESSION, 
Presenuition  TP4, 
CLNS, 


IEEE  802,  Bridges, 
Routers,  and 
Application  Layer 
Gateways 


•  Conformtince/ 
Interoperability  Test 
Tools  and  Methods 

•  Application 
Development  and 
Customization 
Toolkits 

•  Systems  Integration 
Tools 


Application 
Programming 
Interfaces  (APIs) 


A-60 


Title:  National  Center  for  Manufacturing  Sciences/Computer  Integrated 
Operations  (NCMS/CIO)  -  Organization 

Scope:  Developing  and  promoting  information  integration  efforts  for  manufacturing. 
NCMS  has  sponsored  work  in  the  area  of  Next  Generation  Controller  (NGC),  Manufactur¬ 
ing  Automation  Protocol/Technical  and  Office  Protocol  (MAP/TOP)  study.  Media  Access 
Selection,  Manufacturing  Message  Specification  (MMS)  promotion,  and  a  program  in 
Design  for  Integration. 

Level  of  Effort:  NCMS  is  a  consortium  of  manufacturing  companies.  The  funding  comes 
from  membership  dues  and  supporting  Federal  funds.  Revenue  from  royalties  accrued 
based  on  technology  transfer  activities  is  also  anticipated.  NCMS  has  around  140  mem¬ 
bers. 

Performers:  Most  of  the  strategic  planning  is  done  by  various  special  interest  groups 
(SIGs)  within  NCMS.  These  SIGs  are  formed  by  representatives  from  member  compa¬ 
nies.  Projects  are  approved  by  SIGs  and  executed  by  member  companies. 

Duration:  Ongoing. 

Intent:  To  support  and  promote  the  development  and  transfer  of  advanced  manufacturing 
technologies  to  member  companies. 

Description  of  Work  Done:  NCMS  has  sponsored  several  information  technology 
related  projects  for  manufacturing.  They  include  NGC  needs  and  requirements,  a  MAP/ 
TOP  study.  Media  Access  Selection  for  manufacturing  networks,  MMS  promotion,  and 
(currently)  a  design  for  integration  program.  NCMS  has  also  engaged  in  number  of  tech¬ 
nology  transfer  activities  in  these  areas. 

Results:  NCMS  has  completed  reports  on  NGC  needs  and  requirements.  It  has  also  com¬ 
pleted  the  MAP/TOP  and  media  access  selection  study.  NCMS  is  actively  promoting 
MMS  and  has  developed  a  tutorial,  a  white  paper,  and  a  MMS  product  guide. 

Technology  Transfer  Approach  and  Plans:  NCMS  has  a  separate  technology  transfer 
division  working  on  the  issues  of  transferring  results  of  the  projects  to  member  compa¬ 
nies.  These  activities  include  “hand  holding,”  education  and  training,  and  developing  and/ 
or  supporting  computer-based  tools. 
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Table  A- 14.  National  Center  for  Manufacturing  Sciences/Computer  Integrated 

Operations  (NCMS/CIO)  Matrix 


Technical  Categories 

Integration 
Fnuneworks  and 
Architectures 

Operating  Systems  and 

Distributed 

Environments 


Communications 


DaUi  Management 
Systems 

Application 
Development  Tools 
and  Methods 

Daui  Represenuitions 

Information  Modeling 
Tools  and  Methods 

User  Interfaces 

Programming 

Lc'inguages 

Security  Tools  and 
Methods 
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Title:  National  Institute  of  Standards  and  Technology  (NIST)  Shop  of  the  90s  - 
NIST  Program 

Scope:  An  effort  to  integrate  the  typical  design  to  manufacturing  functions  required  in  a 
small  machine  shop. 

Level  of  Effort:  Approximately  $200K  per  year,  2.5  full-time  equivalent  (FTE),  plus 
donated  hardware  and  software. 

Performers:  NIST  shops  personnel. 

Duration:  Official  start,  1986;  effective  start  1988;  continuing  at  least  through  FY  1992. 

Intent;  The  purpose  of  this  project  is  to  demonstrate  that  a  typical  machine  shop  can  inte¬ 
grate  the  design  and  manufacturing  functions  via  a  computer  network  assembled  out  of 
readily  available  components.  The  overall  objective  of  the  project  is  the  broad  adoption  of 
existing  shop-integrating  technologies  by  small  machine  shops.  This  is  based  on  the  belief 
that  this  kind  of  change  in  the  way  the  shops  operate  will  make  them  more  competitive. 
The  biggest  barrier  to  machine  shop  integration  is  the  lack  of  belief  and  trust  in  the  claims 
of  the  existing  integration  tool  vendors  resulting  from  previous  disappointments.  The 
project  arose  out  of  the  recognition  that  the  previously  existing  Automated  Manufacturing 
Research  Facility  was  doing  work  which  was  primarily  going  to  be  of  use  to  large  firms. 
The  Shop  of  the  90s  was  seen  as  the  small  firm  solution. 

Description  of  Work  Done:  A  working  machine  shop  within  NIST  was  integrated  via  the 
use  of  commercial  off-the-shelf  (COTS)  hardware  and  software.  Most  of  the  equipment 
and  software  was  donated  to  the  program.  The  approach  is  entirely  designed  around  exist¬ 
ing,  commonly  available  IBM  personal  computer  (PC)  compatible  microcomputer  hard¬ 
ware  and  software  (including  MS-DOS  as  the  operating  system),  along  with  standard 
machine  tools  and  coordinate  measuring  machines.  These  include  commercial  computer- 
assisted  design  (CAD),  computer-assisted  manufacturing  (CAM),  project-planning  and 
tracking  and  other  software.  The  computer  system  is  composed  of  a  set  of  PCs  connected 
by  an  IBM  local  area  network.  Most  of  the  equipment  was  donated  by  a  set  of  vendors 
supporting  the  work.  The  PCs  are  dedicated  to  specific  functions,  but  that  need  not  be  the 
case  in  smaller  shops.  The  entire  concept  can  be  run  on  one  machine. 

Results:  There  has  been  a  great  deal  of  interest  in  the  program,  especially  from  state  agen¬ 
cies  which  have  used  Shop  of  the  90s  personnel  in  seminars  and  workshops.  Additional 
interest  is  represented  by  the  continuous  stream  of  visitors  who  wish  to  investigate  the 
Shop  of  the  90s. 
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Cost  justification  has  been  based  on  the  concept  that  the  Shop  of  the  90s  is  a  working 
machine  shop,  competing  with  outside  shops  for  internal  NIST  business.  The  project  has 
included  a  number  of  vendors  as  partners  who  have  strong  interests  in  making  their  prod¬ 
ucts  work  in  such  integrated  systems.  The  main  functional  goal  of  the  project  was  to  link 
the  various  hardware  and  software  systems  into  a  functioning,  integrated  whole  using 
COTS  technologies.  This  has  been  accomplished. 

Technology  Transfer  Approach  and  Plan:  Dissemination  of  results  has  been  primarily 
through  seminars,  workshops,  and  demonstrations  (often  on  the  road)  plus  frequent  visi¬ 
tors  at  the  NIST  facility.  The  traveling  shows  are  limited  by  the  budget,  especially  since 
recent  tightening  of  rules  has  made  it  difficult,  if  not  impossible,  for  non-Federal  organiza¬ 
tions  to  share  the  cost.  The  road  shows  are  delivered  only  at  the  written  invitation  of  some 
Federal  or  state  agency  or  a  non-profit  organization.  The  audience  may  be  made  up  of  pri¬ 
vate  companies,  but  a  for-profit  cannot  be  the  sponsor.  Generally,  outside  visitors  to  the 
NIST  site  also  must  be  sponsored  by  an  appropriate  agency. 

There  is  also  a  “beta”  test  site  at  a  machine  shop  located  near  Baltimore,  Maryland,  where 
a  similarly  integrated  shop  is  in  operation  to  demonstrate  that  a  “real”  shop  can  also  use 
the  Shop  of  the  90s  approach.  The  assistance  given  to  that  shop  is  in  exchange  for  access 
by  NIST  and  other  organizations. 

In  addition,  many  articles  have  been  placed  in  newspapers  and  widely  read  trade  and 
industry  magazines.  Those  have  served  to  stimulate  interest  in  further  information.  There 
are  currently  no  plans  to  do  any  transfer  activities  outside  of  the  ones  listed  here.  Given 
the  uncertainty  of  funding  after  FY  1992,  the  focus  is  shifting  from  transfer  to  further 
technology  work,  so  that  as  much  ground  can  be  covered  as  possible,  should  the  funding 
disappear. 

Linkages:  The  Shop  of  the  90s  is  based  on  the  de  facto  standards  of  IBM-compatible 
computers  and  the  MS-DOS  operating  system.  These  form  the  platform  upon  which  the 
project  was  built.  Outside  of  the  contributions  of  the  hardware  and  software  vendors,  there 
is  litde  linkage  to  any  other  effort. 

References: 

Baum,  M.  The  Shop  of  the  90s.  Gaithersburg,  MD;  National  Institute  of  Standards  and 
Technology,  [n.d.]  NIST  Special  Publication  770. 
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National  Institute  of  Standards  and  Technology.  Manufacturers,  Skiers  Gain  Competitive 
Edge.  Gaithersburg,  MD:  National  Institute  of  Standards  and  Technology,  [n.d.] 
NIST  Special  Publication  809. 

Primary  contact: 

Adrian  Moll,  Chief 

Fabrication  Technology  Division 

National  Institute  of  Standards  and  Technology 

(301)975-6504 


Table  A-15.  National  Institute  of  Standards  and  Technologies  (NIST) 

Shop  of  the  90s  Matrix 


TechniciiJ  Categories 

Business  View 

Infonnation  View 

Integration 

FraineworLs  and 
Architectures 

Operating  Systems  and 

Distributed 

Environments 

•  MS-DOS 

Communications 

♦  IBM  Proprietiiry 

LAN 

Data  M^inagement 
Systems 

•  MS-DOS  File  Server 

Application 
Development  Tools 
and  Methods 

Data  Representations 

•  Proprietary  to 
Commercial 

Software 

Information  Modeling 
Tools  <ind  Methods 

User  Interfaces 

Prognunming 

Languages 

Security  Tools  and 
Methods 

Title:  Open  Distributed  Processing  (ODP)  -  American  National  Standards  Institute 
(ANSI)  Program 

Scope:  ODP  is  chartered  to  produce  an  international  standard  reference  model  for  distrib¬ 
uted  processing. 

Level  of  Effort:  Currently,  only  the  members  of  the  U.S.  and  international  committees  are 
engaged  in  definition  of  the  reference  model.  A  European  group  is  currently  developing 
prototype  ODP  software.  A  U.S.  group  (ODP  Consortium  or  ODPC)  is  currently  in  the 
formation  stages  to  ensure  that  an  adequate  testing  infrastructure  exists  to  ensure  accep¬ 
tance  of  the  ODP  standard. 

Performers: 

•  X3T3  Committee  -  Development  of  ODP  reference  model 

•  Open  Distributed  Processing  Testbed  Initiative  (ODPTl)  -  Conformance  and 
interoperability  testing 

•  Advanced  Network  Systems  Architecture  (ANSA)  -  Prototype  ODP  software 
Duration:  1987  represent. 

Intent:  The  ODP  effort  began  to  produce  a  reference  model  for  distributed  processing. 
The  reference  model  will  form  the  basis  for  distributed  processing  standards  which  will 
allow  compliant  applications  to  communicate  in  a  transparent  manner.  This  is  a  key  effort 
since  no  enterprise  integration  effort  can  expect  to  get  far  without  the  ability  to  communi¬ 
cate  transparently  between  applications. 

Description  of  Work  Done:  ODP  work  is  progressing  along  three  fronts.  The  first  of 
these  is  the  development  of  the  ODP  reference  model.  Second,  the  reference  model  is 
being  used  as  the  basis  for  a  prototype  ODP  system,  ANSA.  Finally,  ODPC  is  being  set  up 
to  provide  the  testing  infrastructure  needed  to  support  products. 

Results:  The  ODP  standards  effort  is  focusing  on  developing  a  unified  model  of  objects. 
To  accomplish  this,  they  have  identified  five  viewpoints: 

•  Enterprise  View.  The  Enterprise  View  describes  objects  in  terms  of  the  expec¬ 
tations  of  the  entire  enterprise,  including  policies  and  procedures.  However, 
aspects  of  an  enterprise  which  have  nothing  to  do  with  computation  are  not  rep¬ 
resented. 


•  Information  View.  The  Information  View  focuses  on  the  information  processing 
requirements  of  objects.  It  models  the  information  structure  and  relationships  of 
both  manual  and  automatic  processing. 

•  Computation  View.  The  Computation  View  concentrates  on  the  structure  of  the 
applications  (what  functions  will  run  where).  It  is  independent  of  the  specific 
hardware  to  be  used  and  represents  a  computational  model  of  the  Information 
View. 

•  Engineering  View.  The  Engineering  View  concerns  support  aspects  of  applica¬ 
tions.  This  includes  the  needs  for  performance,  reliability,  and  security. 

•  Technology  View.  The  Technology  View  concerns  the  actual  realization  and 
implementation  of  the  components.  This  view  addresses  exactly  what  hardware 
and  software  is  needed  to  implement  the  specified  distributed  system. 

In  addition  to  these  viewpoints,  the  ODP  effort  is  addressing  issues  of  controlling  the  dis¬ 
tributed  name  space.  This  work  involves  a  process  called  Trading.  A  Trader  will  take  the 
name  of  a  desired  service  and  return  an  interface  to  a  server  which  can  provide  the  desired 
service.  A  trader  however  is  more  complex  than  existing  name  service  facilities.  An  ODP 
trader  can  provide  access  to  a  service  similar  to  the  desired  one  if  an  exact  match  is  not 
available.  The  trader  in  some  concepts  also  controls  all  communications  between  servers 
and  clients. 

To  develop  prototype  software,  a  European  consortium  called  Architecture  Projects  Man¬ 
agement  Ltd.  (APM)  has  been  formed.  APM  currently  has  a  prototype  ODP  system. 
ANSA.  ANSA  consists  of  a  mechanism  for  interprocess  communication  and  a  prototype 
Trader.  Using  ANSA,  distributed  applications  can  register  interfaces  for  the  services  they 
provide,  query  the  Trader  to  find  interfaces  to  desired  services,  and  communicate  with 
applications  providing  those  services. 

Technology  Transfer  Approach  and  Plans:  ODPC  was  formed  to  address  technology 
transfer  issues.  The  consortium’s  main  goal  initially  is  to  develop  and  support  the  infra¬ 
structure  needed  to  support  the  standard  when  it  is  developed.  This  includes  a  test  center 
for  conformance  and  interoperability  testing  and  for  sample  applications.  ODPC  has  a 
grant  of  $3  million  from  ESPRIT  to  fund  this  work. 

Primary  Contacts: 

Ed  Stull  Jack  Veenstra 

ODPC  ANSI  ODP 

(301)  942-4355  (908)  576-4390 
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Table  A-16.  Open  Distributed  Processing  (ODP)  Matrix 


Technical  Categories 

Business  View 

Infonnation  View 

Technology  View 

Integration 

Fnuneworks  and 
Architectures 

•  ODP  Reference 

Model 

•  Enterprise  View 

•  ODP  Reference 

Model 

•  Information  View 

•  Compuuition  View 

•  ODP  Reference  View 

•  Engineering  View 

•  Technology  View 

Operating  Systems  <ind 

Distributed 

Environments 

•  Trader 

•  Trader 

Communications 

•  OSl 

Data  Management 
Systems 

Application 
Development  Tools 
tind  Methods 

DaUi  Representiitions 

Information  Modeling 
Tools  joid  Methods 

User  Interfaces 

Programming 

Liuiguages 

Security  Tools  tmd 
Methods 

•  Trader 

Title:  Object  Management  Group  (OMG)  -  Organization 

Level  of  Effort:  International,  U.S. -based  consortium  of  about  270  members. 

Performers:  Member  companies,  OMG  staff. 

Duration:  Ongoing,  begun  in  1989. 

Primary  Milestones: 

•  Founded  (April  1989) 

•  Object  Management  Architecture  Guide  (September  1990) 

•  Object  Request  Broker  Request  for  Proposal  (RFP)  (October  1990) 

•  Object  Model  Request  for  Information  (RFT)  (March  1991) 

•  The  Common  Object  Request  Broker  Architecture  and  Specification  (COR- 
BA),  Revision  1.1  (December  1991) 

•  Object  Management  Architecture  Guide,  Revision  2.0  (September  1992) 

•  Object  Services  RFP  (October  1992) 

•  C++  Language  Mapping  RFP  (December  1992) 

•  Object  Request  Broker  2.0  Extensions  RFI  (January  1993) 

Intent:  OMG  is  dedicated  to  maximizing  the  portability,  reusability,  and  interoperability 
of  computer  software  and  the  business  benefits  derived  from  them.  The  OMG  is  commit¬ 
ted  to  creating  a  framework  and  supporting  specifications  for  commercially  available 
object-oriented  environments. 

The  OMG  provides  a  reference  architecture  with  terms  and  definitions  upon  which  all 
adopted  specifications  are  based.  Implementations  of  these  specifications  will  be  made 
available  under  fair  and  equitable  terms  and  conditions.  The  OMG  will  create  industry 
standards  for  commercially  available  object-oriented  systems,  emphasizing  distributed 
applications  development. 

The  OMG  provides  an  open  forum  for  industry  discussion,  education,  and  promotion  of 
OMG-endorsed  technologies.  The  OMG  coordinates  its  activities  with  related  organiza¬ 
tions  and  acts  as  a  technology  marketing  center  for  information  on  object-oriented  soft¬ 
ware. 

The  overall  technical  goal  of  OMG  is  to  adopt  interface  and  protocol  specifications  that 
define  an  object  management  architecture  supporting  interoperable  applications  based  on 
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distributed  interoperating  objects.  The  specifications  are  to  be  based  on  existing  technolo¬ 
gies  that  can  be  demonstrated  to  satisfy  OMG’s  Technical  Objectives. 

Description  of  Work  Done:  The  technical  work  of  the  OMG  is  done  in  the  Technical 
Committee  (TC).  The  TC  has  subcommittees  (including  Reference  Model  and  Object 
Model  subcommittees).  Task  Forces,  and  Special  Interest  Groups  (SIGs).  SIGs  have  been 
formed  for  Class  Libraries,  Databases,  Object  Query,  Analysis  &  Design,  End-User 
Requirements,  and  Parallel  Object  Systems. 

OMG’s  standards  are  based  on  existing  technology.  The  adoption  process  is  for  a  Task 
Force  of  the  TC  to  issue  an  RFI;  then  based  on  the  responses,  to  issue  an  RFP.  The  task 
force  evaluates  the  proposals  and  recommends  action  to  the  TC.  At  present  there  are  four 
task  forces:  Object  Request  Broker  (ORB),  Object  Model  Revision,  Object  Services,  and 
ORB  Revision. 

In  1989  OMG  developed  its  Object  Management  Architecture  (OMA),  described  in  the 
Reference  Model  section  of  the  Object  Management  Architecture  Guide.  The  reference 
model  provides  a  conceptual  roadmap  for  assembling  technology  that  satisfies  OMG’s 
technical  objectives.  It  is  intended  to  influence  the  high-level  architecture  and  component 
designs  of  specific  proposed  approaches  while  accommodating  a  variety  of  design  solu¬ 
tions.  Thus,  the  reference  model  identifies  the  major  components  of  OMA  and  describes 
the  functions  of  each  component.  It  also  describes  the  permitted  interactions  among  com¬ 
ponents  and  the  interfaces  for  such  interaction.  The  OMA  has  four  main  components: 
Application  Objects,  Common  Facilities,  Object  Services,  and  the  ORB. 

CORBA,  a  realization  of  the  ORB  component  of  the  OMA,  was  the  first  technology 
adopted  by  the  OMG.  It  describes  the  interfaces  for  accessing  object  in  a  distributed  envi¬ 
ronment.  An  interface  definition  language,  a  dynamic  interface,  and  a  read-only  interface 
to  an  object  repository  have  been  established. 

The  Interface  Definition  Language  (IDL)  is  the  interface  to  the  ORB  Core.  It  is  a  language 
binding  meant  to  make  a  sub-system  available  from  a  given  language.  IDL  will  enable 
language-independent  object  interfaces  to  achieve  /Vtfmoperability  and  inftToperability  of 
ORBs.  The  only  language  currently  supported  is  ANSI  C,  and  responses  to  the  RFP  to 
standardize  on  IDL  mappings  for  C-(-4-  were  due  in  April  1993. 

The  most  crucial  component  of  the  Object  Services  portion  of  the  OMA  is  a  common 
object  model  for  describing  object/class  structure.  The  object  model  defines  a  language- 
independent  object  structure  and  appropriate  components  and  profiles.  It  will  be  used  as  a 


basis  for  defining  design  portability  across  all  OMG  specifications.  The  Core  Object 
Model  has  been  published  in  revision  2.0  of  the  Object  Management  Architecture  Guide. 
The  component  and  profile  sections  of  the  object  model  will  be  done  separately. 

Once  the  ORB  and  Object  Model  are  in  place,  a  group  of  important  lower-level  Object 
Services  is  necessary  to  make  a  commercially  viable  system.  The  Object  Services  task 
force  issued  an  RFP  for  event  notification,  life  cycle,  naming,  and  persistence  services; 
responses  were  due  in  February  1993. 

Technology  Transfer  Approach  and  Plans:  A  major  means  of  technology  transfer  is 
through  the  participation  of  member  company  staff.  Furthermore,  the  RFI-RFP  approach 
to  acquiring  new  technology  components  also  provides  a  means  of  transferring  technology 
and  promoting  awareness. 

Linkages:  OMG  members.  International  Organization  for  Standardization  (ISO)  JTCl/ 
SC21AVG7,  American  National  Standards  Institute  (ANSI)  X3T3,  Open  Software  Foun¬ 
dation  (OSF),  Unix  International  (UI). 

OMG  specifies  the  use  of  existing  technology  and  standards  like  X/Open  endorsed  stan¬ 
dards,  the  Portable  Operating  System  Interface  for  Common  Environments  (POSIX), 
ANSI  C,  and  networking  protocols  like  the  Open  Systems  Interconnection  (OSI)  and  the 
Transmis.sion  Control  Protocol/Internet  Protocol  (TCP/IP).  Its  goal  is  to  use  popular  stan¬ 
dards  where  possible. 

References: 

Object  Management  Group.  The  Common  Object  Request  Broker:  Architecture  and  Spec¬ 
ification  (CORBA),  Revision  1.1.  December  1991.  OMG  Document  91.12.1. 

Object  Management  Group.  Object  Services  Architecture,  Revision  6.0.  August  1992. 
OMG  Document  92.8.4. 

Object  Management  Group.  Object  Management  Architecture  Guide,  Revision  2.0.  Sep¬ 
tember  1 992.  OMG  Document  92. 1 1 . 1 . 
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Table  A-17.  Object  Management  Group  (OMG)  Matrix 


Technical  Categories 

Business  View 

Information  View 

Integration 

Frameworks  and 
Architectures 

•  OMG  Object  Model 

•  OMA  Reference 

Model 

•  Clcissical  Object 

Model 

•  Generalized  Object 
Model 

Operating  Systems  iind 

Distributed 

Environments 

•  Object  Services 

•  Common  Facilities 

•  System  Management 

Communications 

•  Object  Request 

Broker 

•  Object  Model 

•  Interface  Definition 
Language 

Daui  Management 
Systems 

•  Distributed  Object 
Management 

•  OODBMS 

♦  Object  Services 

Application 
Development  Tools 
and  Methods 

•  Object  Factory 

•  Common  Facilities 

•  OO  CASE  Tools, 
Rapid  Prototyping 

Data  Representations 

•  Application  Objects 

Information  Modeling 
Tools  imd  Methods 

•  Object  Services 

•  Common  Facilities 

User  Interfaces 

•  Object  Interfaces 

Programming 

Languages 

Security  Tools  and 
Methods 

•  Authentication 

•  Discretionary 

Access  Control, 
Concurrency  Control 

Technology  View 


•  OSF/1 

•  DOS 

•  OS/2 

•  Unix 

•  Object  Services 

•  OSl 

•  TCP/IP 

•  X/Open  APIs 

•  RPC 

•  Remote  Object 
Network  Access 

•  APIs  to  OODBMS  & 
RDBMS 

•  Object  Services 


•  XDR 

•  NDR 

•  ASN.l 


•  X/Motif 

•  Windows 

•  ANSIC 


•  C++ 


Title:  Open  Software  Foundation  (OSF)  -  Organization 

Level  of  Effort:  International,  U.S. -based  consortium  of  about  350  members;  OSF  has 
about  280  employees  worldwide. 

Performers:  Member  companies,  OSF  staff. 

Duration:  Continuing. 

Primary  Milestones: 

•  Founded  (May  1988).  Commits  to  compliance  to  X/Open  and  the  Portable 
Operating  System  Interface  for  Common  Environments  (POSIX)  in  developing 
an  open  operating  system. 

•  Announcement  of  Motif  (December  1988). 

•  Distribution  of  Motif  (August  1989). 

•  Release  of  OSF/1  (November  1990). 

•  Announcement  of  the  Distributed  Management  Environment  (DME)  (Septem¬ 
ber  1991). 

•  Release  of  the  Distributed  Computing  Environment  (DCE)  (December  1991). 

Intent:  OSF  was  formed  in  1988  to  counter  what  was  generally  perceived  to  be  AT&T’s 
“unfair  advantage”  in  determining  the  direction  of  Unix  specifications.  It  would  be  wrong, 
however,  to  think  of  OSF  only  as  a  specifier  of  an  operating  system.  As  of  late  it  has  been 
releasing  specifications  for  a  DCE  and  a  DME.  These  specifications  will  be  based  on 
existing  products  but  will  support  international  as  well  as  industry  standards. 

Description  of  Work  Done:  OSF/1  is  based  on  IBM’s  AIX  operating  system  and  the  Car- 
negie-MeUon  “real-time  Unix”  operating  system,  Mach.  OSF  releases  so-called  snapshot 
versions  to  its  members,  prior  to  general  release.  The  snapshot  release  was  started  in 
November  1990.  OSF/1  was  released  for  general  distribution  in  November  1990. 

In  addition  to  an  operation  system,  OSF  has  release  its  version  of  a  graphical  user  inter¬ 
face  (GUI)  toolkit  for  use  in  an  X-Windows  environment.  Motif.  Motif  has  competition 
from  Unix  International’s  OpenLook  but  is  generally  considered  to  have  a  substantial  lead 
in  applications  being  developed  by  independent  software  vendors.  Motif  1.1  is  the  latest 
update  to  Motif  (May  1991). 

On  June  13,  1989,  OSF  issued  an  Request  for  Technology  (RFT)  for  the  DCE.  The 
response  were  expected  to  address  solutions  to  the  problems  of  creation,  use,  and  support 


of  distributed  applications.  It  received  50  letters  of  intent  to  submit.  Thirty-two  organiza¬ 
tions  submitted  twenty-nine  proposals.  On  May  14,  1990,  OSF  announced  the  results. 

DME  is  OSF’s  solution  to  both  system  and  network  management.  In  July  1990,  OSF 
issued  an  RFT  for  DME  and,  by  the  end  of  September,  had  received  42  responses.  The 
technologies  selected  include  a  “comprehensive  and  cohesive  management  model  consist¬ 
ing  of  a  user  interface,  a  management  infrastructure  with  object  and  event  services,  appli¬ 
cation  services,  such  as  software  licensing,  installation  and  printer  management,  plus  a 
host  management  facility.”  On  September  17,  1991,  an  announcement  was  made  of  the 
technologies  selected. 

Technology  Transfer  Approach  and  Plans:  OSF’s  method  for  technology  transfer  rests 
on  four  cornerstones: 

♦  Special  interest  groups  (SIGs)  define  the  scope  and  requirements  for  the  RFTs. 

•  The  RFT  process  (Open  Technology  Acquisition).  OSF  issues  an  RFT  via 
numerous  channels.  OSF  members,  industry  consultants,  standards  groups,  and 
RTF  respondents  evaluate  the  RFT. 

♦  Member  meetings  provide  forums  for  ideas,  review,  and  input  to  evaluation 
teams. 

•  Technology  “snapshots”  are  provided  to  members.  These  are  technologies 
under  development.  The  intent  is  for  members  to  provide  feedback,  similar  to 
beta  testing. 

After  these  steps  listed  above,  the  specifications  are  put  into  general  release. 

Linkages:  OSF  members,  X/Open,  the  National  Institute  for  Standards  and  Technology 
(NIST),  the  Portable  Operating  System  Interface  for  Computer  Environments  (POSIX), 
the  Internet  Activities  Board  (lAB),  OSI/NM  Forum,  the  Object  Management  Group 
(OMG). 


Table  A- 18.  Open  Software  Foundation  (OSF)  Matrix 


Technical  Categories 


Integration 
Fnimeworks  iind 
Architectures 


Operating  Systems  ^ind 

Distributed 

Environments 


Communications 


DaUi  Mtinagement 
Systems 


Application 
Development  Tools 
and  Methods 


Data  Representations 


Infonuation  Modeling 
Tools  Jind  Methods 


User  Interfaces 


Programming 

Liuiguages 


Security  Tools  and 
Methods 


Business  View 


Strategic  Marketing  - 
Prevent  AT&T/SUN 
from  monopolizing 
Unix  mcU'kets  (i.e., 
Unix  and  open 
systems) 


Infonnation  View 


Distributed 

Computing 


Technology  View 


Table  A-19.  Open  Software  Foundation  (OSF)/ 
Distributed  Computing  Environment  (DCE)  Matrix 


Technical  Categories 

Integration 
Fmmeworks  and 
Architectures 


Operating  Systems  and 

Distributed 

Environments 


Communications 


DaUi  Management 
Systems 


Application 
Development  Tools 
tmd  Methods 


Data  Representations 


Information  Modeling 
Tools  and  Methods 

User  Interface 

Programming 

Languages 

Security  Tools  tmd 
Methods 


Business  View 

Information  View 

Technology  View 

•  DCE  Architecture 

•  Distributed 
Management 
Environments 

•  Distributed  Naming 
Service 

•  Naming  Service 

•  Time  Service 

•  DOS,  OS/2 

•  Unix  (POSIX),  AIX, 
ULTRIX,  Domain 

OS,  HP-UX,  SINIX 

•  X.500  Domain  Name 
Service,  Network 

Time  Protocol 

•  NFS,SMBP 

•  RCP 

•  High-level  interface 
description  compiler 

•  Pipes,  ODP,  OSI, 
TCP/IP,  OS/2 

•  Threads 

•  POSIX  1003.4a 

•  Distributed  File 

System 

•  NFS  “Only- 
compatible” 

•  RPC 

•  POSIX  1003.1 


•  X.509  •  Encryption  •  Access  control  lists 

•  POSIX  1003.6  •  Authentication  •  Kerberos 
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Title;  Product  Data  Exchange  Specification  (PDES)  Using  STandard  for  the 
Exchange  of  Product  Data  (STEP)  -  IGES/PDES  Organization  (IPO) 
Program 

Level  of  Effort:  Primarily  volunteer  effort,  with  some  support  from  the  Department  of 
Defense  (DoD)  Continuous  Acquisition  and  Lifecycle  Support  (CALS)  program. 

Performers:  Members  of  the  Initial  Graphics  Exchange  Specification  (IGES)/PDES 
Organization  (IPO)  in  association  with  the  International  Organization  for  Standardization 
(ISO)  TC184/SC4. 

Duration:  Ongoing. 

Primary  Milestones:  Completion  of  Version  1  of  STEP,  expected  some  time  in  early 
1992. 

Intent:  PDES  is  the  U.S.  effort  in  support  of  the  international  development  of  STEP 
(STandard  for  the  Exchange  of  Product  data).  STEP  is  intended  to  be  the  standard  under 
which  product  data  can  be  transferred  within  or  between  enterprises.  In  the  STEP  arena, 
product  data  includes  any  information  required  for  the  design,  manufacture,  and  support 
of  a  product. 

Results:  STEP  is  a  very  large  standard.  As  a  result,  it  is  being  assembled  by  approving  a 
variety  of  “Parts”  that  each  concentrate  on  a  specific  piece  of  the  overall  standard.  To  date, 
progress  is  nearly  complete  on  what  is  being  called  Version  1  of  STEP.  Version  1  will  not 
include  many  of  the  Parts  which  are  planned. 

Technology  Transfer  Approach  and  Plans:  The  CALS  program  has  established  a 
CALS  Shared  Resource  Center  (CSRC)  at  Metalworking  Technology,  Inc.,  in  Johnstown, 
Pennsylvania,  to  assist  small  DoD  suppliers  in  adopting  CALS  standards  and  technolo¬ 
gies.  Since  PDES  is  one  of  the  CALS  technologies,  the  CSRC  will  serve  as  an  avenue  for 
STEP  technology  transfer.  In  addition,  the  U.S.  Navy  is  funding  the  development  of  tools 
which  will  help  in  STEP  adoption. 

Linkages;  Direct  contact  between  the  IPO  committees  and  ISO  TC184/SC4  working 
groups. 

References: 

National  Computer  Graphics  Association.  IGESlPDES  Organization  Reference  Manual. 
July  1991. 
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Primary  contacts: 


William  Conroy,  Chair  Anthony  Day,  PDES  Chuck  McLean 

IGES/PDES  Project  Manager  National  PDES  Testbed 

Organization  IGES/PDES  NIST 

(301)  975-398 1  Organization  (30 1 )  975-35 1 1 

(203)  386-5320 


Matrix  Notes: 

Application  Protocols  (APs).  Basic  pieces  in  which  STEP  is  going  to  be  implemented. 
An  AP  defines  the  use  of  the  basic  bits  and  pieces  of  STEP  so  that  through  the  AP,  one  can 
transfer  all  the  data  necessary  to  define  an  idea  or  concept  related  to  a  product.  The  devel¬ 
opment  of  hundreds,  if  not  thousands  of  APs,  is  expected  for  the  wide  variety  of  products 
covered  by  STEP,  from  garments  to  aircraft  to  documents. 


Table  A-20.  Product  Data  Exchange  Specification  (PDES)  Matrix 


Technical  Categories 


Business  View 


Infonnation  View 


Technology  View 


Integration 
Fnuneworks  juid 
Architectures 


Operating  Systems  and 

Distributed 

Environments 


Communications 


Data  Mjinagement 
Systems 


Application 
Development  Tools 
and  Methods 


Daui  Representations 


Infonnation  Modeling 
Tools  and  Methods 


User  Interface 


Programming 

Languages 


Security  Tools  and 
Methods 


Application 

Protocols 


Application 

Protocols 


Application  Protocol 
Dahl  Models 


EXPRESS 


Application 

Protocols 


•  EXPRESS 

•  EXPRESS -G 

•  EXPRESS 

•  IDEFO 

•  NIAM 

♦  EXPRESS 

Title:  Portable  Operating  System  Interface  for  Common  Environments  (POSIX)  - 
IEEE  program 

Level  of  Effort:  Many  hundreds  of  person-years. 

Performers:  The  POSIX  effort  is  sponsored  by  the  Institute  of  Electrical  and  Electronics 
Engineers  (IEEE),  Inc.  Committee  members  are  drawn  from  different  companies. 

Primary  Milestones:  Work  on  this  effort  dates  back  to  1984  when  UniForum  (formerly 
/usr/ group)  published  its  /us r/ group  Standard  in  an  attempt  to  standardize  a  profusion 
of  Unix-based  systems  for  minicomputers  and  microcomputers  appearing  in  the  market. 
Subsequently,  in  1985,  this  work  was  transferred  to  IEEE.  In  1987,  IEEE,  with  the  support 
of  /usr/group,  brought  POSIX  to  the  International  Organization  for  Standardization 
(ISO).  IEEE  1003.1  first  appeared  as  a  standard  in  1988,  and  the  ISO  standard  appeared  in 
1990,  along  with  IEEE  1003.1  1990. 

The  first  standard  developed  in  this  family  is  IEEE  1003.1,  also  known  as  ISO/IEC  9945- 
1,  Information  Technology — Portable  Operating  System  Interface — Part  I:  System  Appli¬ 
cation  Programming  Interface  (API)  in  the  C  Language. 

Intent:  The  POSIX  effort  was  established  with  the  primary  purpose  of  achieving  portabil¬ 
ity  of  applications  written  by  users  and  developers. 

•  The  primary  objective  is  to  achieve  source  portability  of  application  programs 
over  a  wide  variety  of  Unix  platforms  using  existing  definitions  of  the  Unix  sys¬ 
tem. 

•  Only  the  interface  is  to  be  defined,  without  stipulating  the  implementation 
approach  which  is  left  to  the  vendor. 

•  As  far  as  possible,  only  one  means  of  realizing  a  capability  has  been  specified. 

•  As  far  as  possible,  POSIX  tries  to  accommodate  popular  historical  implementa¬ 
tions  by  following  a  “minimal  change”  philosophy.  This  minimizes  the  addi¬ 
tional  work  to  be  done  by  application  developers. 

•  Alignment  with  other  concurrent  activities  within  the  POSEX  effort  is  main¬ 
tained. 

The  activities  under  the  POSIX  umbrella  are  as  follows: 

•  Language-independent  descriptions  of  the  system  interface  specified  in  IEEE 
1003.1. 

•  C,  Ada,  and  Fortran  bindings  for  the  above. 

•  Shell  and  utility  facilities. 


•  Verification  testing  methods. 

•  Real-time  facilities. 

•  Security  considerations. 

•  Network  interface  facilities. 

•  System  administration. 

•  Graphical  user  interfaces. 

•  Profiles  for  different  classes  of  platforms  like  supercomputers,  multiprocessors, 
real-time  systems,  and  transaction  processing  systems. 

Thus,  POSIX  is  an  “umbrella  effort”  that  offers  broad  coverage  of  the  features  and  facili¬ 
ties  required  to  develop  and  maintain  highly  portable  applications.  From  a  generic  indus¬ 
try  view,  it  offers  the  promise  of  a  highly  functional  standardized  interface  without 
specifying  implementation  policy.  At  the  particular  industry  level,  it  will  be  possible  to 
use  just  those  components  of  POSIX  that  are  required.  It  provides  a  key  component  of 
information  integration  in  the  enterprise  by  performing  the  following: 

•  It  allows  applications  to  migrate  to  different  platforms  with  minimum  developer 
effort. 

•  It  offers  developers  and  programmers  a  uniform  interface  which  does  not 
change  in  functionality  (with  platforms)  and  does  require  relearning.  As  a 
result,  development  and  maintenance  are  made  less  expensive. 

•  It  permits  tools  (computer-assisted  software  engineering  (CASE),  development, 
end-user,  management)  to  work  in  the  same  manner  and  across  platforms,  there¬ 
by  consolidating  the  investments  made  in  such  tools. 

•  It  integrates  with  other  services  like  communications  and  user  interfaces  to  offer 
a  highly  transparent  environment  to  user  and  developer  alike. 

Technology  Transfer  Approach  and  Plans:  The  basic  POSIX  technical  approach  is 
already  popular,  being  based  on  Unix.  It  is  (or  will  soon  be)  required  by  many  Federal 
agencies  and  is  rapidly  being  adopted  by  vendors. 

When  products  become  available,  rapid  conformance  testing  can  be  expected.  The 
National  Institute  of  Standards  and  Technology  (NIST)  has  established  a  conformance 
testing  policy  of  POSIX  for  the  Federal  Information  Processing  Standards  (FIPS).  Cur¬ 
rently,  tests  exist  for  the  1003.1-1988  version  of  POSIX  but  efforts  are  underway  to 
update  the  tests  as  new  standards  are  adopted. 


Linkages:  POSIX  is  most  strongly  linked  to  the  Unix  operating  system.  It  also  specifies 
language  bindings  like  C,  Ada,  and  Fortran,  as  well  as  an  API  for  directory  services. 

Primary  Contact:  Roger  Martin,  NIST. 


Table  A-21.  Portable  Operating  System  Interface  for  Common  Environments 

(POSIX)  Matrix 


Technical  Categories 


Business  View 


Information  View 


Technology  View 


Integration  Frameworks 
and  Architectures 


Operating  Systems  and 

Distributed 

Environments 


Communications 


Data  Management 
Systems 


Application 

Development  Tools  and 
Methods 


Data  Representations 


Information  Modeling 
Tools  and  Methods 


User  Interface 


Programming  Languages 


Security  Tools  and 
Methods 


•  File  Transfer 

•  Remote  Execution 


Guide  to  POSIX  Open 
Systems  Environments 
(1003.0) 


Directory  Services 
Naming 


Protocol  Independence 
(1003.12) 

Transparent  File 
Access  (1003.8) 


Multiprocessing  Real- 
Time  Testing  Utilities 


Systems  Services 
(1003.1) 

Real-Time  Extension 
(1003.4) 

System  Administration 
(1003.7) 

Namespace  and 
Directory  Services 
(1003.13) 


X.400  API  (1224) 

Common  OSI  and 
FT  AM  API  (1238. 1&2) 

Remote  Procedure 


Transaction  Processing 
(1003.11) 

Transparent  File  Access 
(1003.8) 


Shell  &  Utilities 
(1003.2) 

Test  Methods  (1003.3) 
Multiprocessing 

(Note:  APIs  could  be 
viewed  as  standard 
libraries.) 


Windowing  Toolkit 
(1201.1) 

X  Lib  (1201.?) 


C  bindings  (1003.1) 

Ada  bindings 
(1003.5) 

Fortran  bindings 
(1003.9) 


Access  Control  Lists 
Audit  Mechanisms 

Privilege  Mechanisms 
(1003.6) 
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Title:  Remote  Database  Access  Protocol  (RDA)  -  International  Organization  for 
Standardization  (ISO)  Program 

Scope:  This  is  a  standardization  effort,  currently  within  the  domain  of  the  ISO. 

Level  of  Effort:  Primarily  volunteer  in  nature,  therefore  difficult  to  estimate.  By  compar¬ 
ison,  it  has  received  light  to  moderate  attention  relative  to  other  ISO  information  technol¬ 
ogy  standards  efforts. 

Performers:  Until  the  involvement  of  ISO,  the  ANSI  X3H2.1  committee  was  the  focus  of 
efforts  through  early  developments.  NIST  has  also  established  a  SIG  group  for  RDA 
within  its  Open  Systems  Interconnection  (OSI)  Implementors’  Workshops. 

Duration:  1986  through  1991  (estimated).  It  is  expected  that  RDA  will  become  a  full  ISO 
standard  by  mid- 1991. 

Intent:  Information  systems  architects  recognized  that  there  was  a  missing  piece  in  the 
ISO  OSI  communications  model  which  had  to  provide  the  mechanisms  required  by  a  dis¬ 
tributed  database  system.  Distributed  database  access  is  viewed  by  many  as  an  important 
ingredient  in  integrating  enterprises.  RDA  is  intended  to  fill  in  this  missing  piece. 

Description  of  Work  Done:  Documents  (and  debates)  describing  the  RDA  standard  have 
been  the  most  visible  output.  It  is  unclear  to  what  degree  development  has  progressed 
within  suppliers. 

Results:  There  is  a  small  group  of  users  which  value  the  RDA  standard.  To  most,  it  is  sub¬ 
stantially  hidden  under  the  covers,  or  obscured  by  its  partner  standards  such  as  TP  (Trans¬ 
action  Processing),  SQL,  CCR  (Commitment,  Concurrency,  and  Recovery  Protocol),  and 
OSI  protocols.  Regardless,  it  is  a  necessary  mechanism  in  the  OSI  scheme  of  things. 

There  is  a  key  user/vendor  group  called  the  SQL  Access  Group  whose  primary  focus  is  the 
advancement  of  the  use  of  the  SQL  data  management  language.  Effective  use  of  RDA 
within  the  SQL  scheme  of  things  is  being  defined  there.  This  may  include  non-OS  I  use  of 
RDA. 

Technology  Transfer  Approach  and  Plans:  A  planned  public  demonstration  of  SQL 
(and  supporting  RDA)  technology  was  planned  for  July  1991.  The  SQL  Access  Group  is 
sponsoring  it;  membership  includes  Apple,  Bull,  Digital  Equipment  Corporation,  Hewlett 
Packard,  Ingres,  Lotus,  Microsoft,  NCR,  Oracle,  Sun,  Sybase,  and  X/Open.  Market  sup¬ 
port  infrastructure  appears  to  be  more  through  SQL  circles  than  OSI  (or  others).  X/Open 


continues  to  include  SQL,  as  promoted  by  the  SQL  Access  Group,  in  the  X/Open  guide¬ 
lines  and  efforts.  Again,  RDA  is  somewhat  under  the  covers  here. 

Linkages:  RDA  was  designed  to  link  with  the  OSI  Communications  standards.  RDA  also 
maintains  some  conceptual  linkage  to  the  ANSI/SPARC  Model  for  Database  Management 
System  (DBMS).  Others  include  standards  work  generated  through  ISO  committee  SC  21, 
and  the  ODP  (Open  Distributed  Processing)  standards. 

References: 

International  Organization  for  Standardization.  ISO  9579,  Generic  RDA  Protocol  and  Ser¬ 
vice  Specifications.  (Specific  version  unidentified  at  time  of  this  report.) 

“SQL  Access;  A  Cure  for  the  Nonstandard  Standard.”  Data  Communications.  March  1991 . 


“Emerging  OSI  Functionality.”  Open  Systems  Data  Transfer.  Omnicom,  Inc.  December 
1989. 


Table  A-22.  Remote  Database  Access  Protocol  (RDA)  Matrix 


Business  View 

Information  View 

Technology  View 

Integration 

Fniine works  and 
Architectures 

•  Distributed 

Dauibases  (DDBMS) 

•  OSI  Model 

•  ANSI/SPARC 

DBMS  Model 

Operating  Systems  iind 

Distributed 

Environments 

•  X/Open 

•  SPG4 

Communications 

•  Client  Server 

•  OSI 

•  MAP/TOP 

♦  ROSE 

♦  ACSE 

♦  TP 

Data  Miinagement 
Systems 

•  Heterogeneous 

DBMSs 

Application 
Development  Tools 
and  Methods 

Dam  Representations 

•  DML(RDA) 

•  ASN.l 

Information  Modeling 
Tools  tind  Methods 

User  Interface 

•  SQL 

Prognunming 

Languages 

•  SQL  G^tinguage 

Binding  TBD) 

Security  Tools  and 
Methods 

•  SQU  Access  FAP 

Title:  SEMATECH  Strategic  Cell  Controller  (SCO  Project  -  SEMATECH 
Program 

Scope:  This  project’s  objective  is  to  drive  the  development  of  cell  controller  technology  as 
it  specifically  applies  to  semiconductor  manufacturing  processes.  The  SCC  project  is 
designed  to  integrate  with  three  other  projects  within  SEMATECH’s  Corporate  Informa¬ 
tion  Management  (CIM)  Architecture  Program.  The  other  projects  are  entitled  Advanced 
Development  Environment,  Systems  Infrastructure,  and  Integrated  Manufacturing  Model. 

Level  of  Effort:  The  entire  SEMATECH  yearly  funding  is  about  $200  million.  Half  is 
from  its  14  members,  and  half  from  the  Defense  Advanced  Research  Projects  Agency 
(DARPA).  The  specific  funding  of  the  SCC  project  is  unavailable. 

Performers:  These  include  participants  from  SEMATECH’s  14  member  companies: 
AMD,  AT&T,  Digital  Equipment  Corporation,  Harris  Corporation,  Hewlett  Packard, 
Intel,  IBM,  LSI  Logic,  Micro,  Motorola,  National,  NCR,  Rockwell,  Texas  Instruments. 
These  participants  (often  30  to  40  individuals  per  company)  will  work  with  SEMATECH 
permanent  staff  for  lengths  of  up  to  2  years. 

Duration:  The  project  is  beginning  this  year  (1991),  and  is  expected  to  last  through  1994. 
It  is  divided  into  two  phases,  each  about  two  years  long. 

Intent:  Cell  control  in  the  semiconductor  industry  is  relatively  primitive  compared  to  cell 
control  in  other  manufacturing  industries.  This,  combined  with  intense  foreign  competi¬ 
tive  pressure,  is  spurring  the  type  of  cooperative  development  represented  by  this  project. 
Further,  in  conjunction  with  the  related  SEMATECH  CIM  projects,  the  SCC  is  an  attempt 
to  break  the  limitations  of  dependency  on  legacy  systems. 

If  the  project  reveals  voids  in  the  current  global  base  of  applicable  standards,  new  stan¬ 
dards  will  be  developed.  One  void  may  be  in  the  area  of  semiconductor  processes  and 
their  models. 

Project  objectives  and  deliverables  will  result  from  each  phase.  The  Phase  1  objective  is  to 
develop  maintainable  and  changeable  semiconductor  cell  controllers.  Phase  2  will  concen¬ 
trate  on  simplifying  controller  programming  so  that  non-programmers  can  do  the  chang¬ 
ing/modifying  (through  the  use  of  high-level  software  modules). 

Description  of  Work  Done:  Object-oriented  tools  and  methods  will  be  the  key 
approaches  and  philosophy  used  in  SCC  development.  Models  and  applications  specific  to 


the  semiconductor  industry  will  be  developed.  Appropriate  standards  will  be  employed 
wherever  possible.  For  instance,  OSF/1  will  provide  the  basic  computing  platform. 

Results:  No  results  have  been  generated  as  yet.  The  hope  is  that  the  results  will  signifi¬ 
cantly  help  productivity.  Many  semiconductor  manufacturers  are  currently  saddled  with 
problems  resulting  from  their  existing  (legacy)  systems.  Appropriate  new  products  and 
processes  are  not  being  developed  fast  enough  to  satisfy  the  needs  of  the  semiconductor 
manufacturing  industry. 

The  results  are  expected  to  be  usable  in  SEMATECH  member  companies  and  available  on 
a  wide  variety  of  hardware  platforms,  with  software  modules  serving  as  an  applications 
platform.  Since  many  member  companies  are  also  platform  hardware  and/or  software  ven¬ 
dors,  such  companies  are  expected  to  provide  results  in  product  form. 

Technology  Transfer  Approach  and  Plans:  Pilot  implementations  are  planned  as  part  of 
the  see  project.  As  mentioned  above,  some  SEMATEeH  companies  will  likely  supply 
the  see  technology  as  products.  SEMATEeH  will  also  work  with  national  labs  and  uni¬ 
versities  to  transfer  technology.  Some  semiconductor  process  standardization  groups  may 
be  organized  to  work  on  areas  not  currently  being  covered.  An  important  project  objective 
is  that  semiconductor  processing  equipment  suppliers  be  able  to  absorb  this  new  technol¬ 
ogy  and  supply  compatible  products,  as  well  as  improve  their  own  product  quality. 

Linkages:  The  object-oriented  philosophies  can  be  found  in  texts  by  authors  such  as  Mel- 
lor,  Booch,  and  Colbert.  Key  standards  will  be  drawn  from  the  OSF/1  sanctioned  profile. 
Tie-ins  to  enterprise  integration  programs  will  be  examined.  Finally,  this  work  will  be 
coordinated  with  the  other  SEMATECH  CIM  Architecture  Programs. 

Primary  Contacts: 

SEMATECH 

2706  Montopolis  Drive 

Austin,  TX  7874 
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Table  A-23.  SEMATECH  Strategic  Cell  Controller  (SCO  Matrix 


Technical  Categories 

Business  View 

Information  View 

Technology  View 

Integration 

Fnimeworks  and 
Architectures 

•  Manufacturing  Plant- 
tO'Cell  Levels 

•  Sematech’s 

Integrated  Model 
(IM) 

•  OSF/l 

•  Sematech  CAS  (CIM 
Systems 

Architecture) 

Operating  Systems  iind 

Distributed 

Environments 

•  OSF/l 

Communications 

•  OSF/l 

DaUi  Miinagement 
Systems 

•  OSF/l 

Application 
Development  Tools 
and  Methods 

•  Object-Oriented 

•  Sematech  ADE 
(Advanced 
Development 
Environment) 

DaUi  Representations 

Information  Modeling 
Tools  and  Methods 

•  Object-Oriented 
Analysis  (Colbert, 
Booch,  Mellor) 

User  Interface 

•  OSF/l 

Programming 

Languages 

•  OSF/l 

Security  Tools  and 
Methods 

•  OSF/l 
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Title:  Transmission  Control  Protocol/Internet  Protocol  (TCP/IP)  -  Department  of 
Defense  Program 

Performers:  BBN,  University  of  California  at  Berkeley,  other  universities. 

Duration:  The  development  of  TCP/IP  began  in  the  mid-1970s,  and  by  the  late  1970s  the 
protocols  took  their  current  form.  In  1980,  TCPAP  adoption  had  begun  and  by  1983  all  the 
hosts  on  the  ARPANET  were  using  it.  In  the  mid-1980s  the  NSFnet  backbone  had  been 
funded.  Currently,  the  lAB  oversees  internet  activities. 

Primary  Milestones:  TCP/IP  is  a  mature  technology  and  is  being  enhanced  in  areas  like 
network  management  (Simple  Network  Management  Protocol  (SNMP)).  Currently,  a  bulk 
of  lAB  work  focuses  on  migration  to  newer  and  more  “standard”  technologies  like  Open 
Systems  Interconnection(OSI). 

Intent:  The  intent  of  developing  the  TCP/IP  protocol  suite  was  to  provide  a  robust,  low- 
cost,  and  easy-to-implement  technology  to  realize  a  national  research  network  that  we 
now  know  as  the  DARPA  Internet. 

Description  of  Work  Done:  TCP  and  IP  are  just  two  protocols  in  the  TCP/IP  suite.  There 
exist  a  large  number  of  other  protocols  in  the  suite  that  perform  other  functions  such  as 
address  resolution,  mail  transfer,  and  network  management.  In  most  part,  the  protocols  are 
stable  and  mature,  and  current  work  focuses  on  enhancements  to  provide  better  functional¬ 
ity  and  interoperability. 

Technology  Transfer  Approach:  DARPA  initially  made  available  the  TCP/IP  protocol 
to  research  and  educational  institutions  at  little  or  no  cost.  Moreover,  since  it  was  built  on 
Berkeley  Unix  (which  was  the  most  popular  operating  system  at  such  institutions),  TCP/ 
IP  gained  wide  acceptance. 

The  lAB  uses  volunteers  to  serve  on  its  task  forces  charged  with  various  responsibilities  to 
maintain  and  improve  ARPANET  services. 

Further  technology  transfer  is  achieved  by  making  the  specifications  public  so  that  ven¬ 
dors  can  use  it.  Currently  there  exist  a  large  number  of  TCP/IP-based  commercial  off-the- 
shelf  (COTS)  products. 

Linkages:  lAB,  International  Organization  for  Standardization  (ISO). 
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Table  A-24.  Transmission  Control  Protocol/Internet  Protocol  (TCP/IP)  Matrix 


Technical  Categories 


Integration 
Frameworks  and 
Architectures 


Operating  Systems  iind 

Distributed 

Environments 


Communications 


DaUi  Management 
Systems 


Application 
Development  Tools 
imd  Methods 


DaUi  Representations 


Information  Modeling 
Tools  and  Methods 


User  Interface 


Prognunming 

Liuiguages 


Security  Tools  imd 
Methods 


Business  View 


Infonnation  View 


Technology  View 


Internetworking 

Peer-to-Peer 

Communications 

Client-Server 

Interaction 


Network 

Maintenjince 

Network 

Mmagement 


Electronic  Mml 
File  Tninsfer 
Remote  Login 


Catenet  Model  (RFC 
871) 

Client-Server  Model 


ProprieUiry 


Hienirchical  Njuning 
(Domain  Niune 
System) 

Internetworking 

Protocol 


POSIX 

ProprieUu*y 

ICMP,  SNMP, 
CMOT 


SMTP,  POP 


TELNET 

DNS 

TCP,  UDP 

IP,  ICMP,EGP,  GGP 


Remote 

Execution 

Network  Application 
Debugging 


Sun  RPC 

Socket  md  Stre^un 
Libraries 

Echo,  Finger,  Ping, 

etc. 


Ad  hoc 
Sun  XDR 


Queuing  Models 
Simulation 


Trusted  Hosts, 
Superusers 

Trusted  Third-Party 
Authentication 


4.3  BSD 
Routines 

MIT  Kerberos 
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Title:  X/Open  -  Organization 

Scope:  Developing  and  promoting  open  systems  technologies.  X/Open  is  working  on 
developing  user  requirements  for  open  systems  and  portability  guides  (XPG),  and  devel¬ 
oping  verification  suites  for  XPGs. 

Level  of  Effort:  X/Open  is  a  consortium  of  users  and  vendors.  It  is  headquartered  in 
United  Kingdom  with  branch  offices  in  the  United  States  and  Japan.  It  has  its  own  full¬ 
time  staff  promoting  open  systems  concepts  by  developing  requirements,  portability 
guides,  and  conformance  test  systems  for  XPGs.  X/Open  is  mainly  funded  by  membership 
dues  and  any  royalties  generated  by  licensing  their  products.  It  has  about  90  members. 

Performers:  X/Open  performs  some  work  in-house  and  some  is  contracted  out  to  other 
companies.  It  has  established  good  working  relationships  with  the  Open  Software  Founda¬ 
tion  (OSF)  and  the  Object  Management  Group  (OMG). 

Duration:  Ongoing. 

Intent:  To  support  and  promote  open  systems  based  technologies.  It  was  formed  as  a  con¬ 
sortium  of  users  and  vendors. 

Description  of  Work  Done:  X/Open  is  working  on  a  user  requirements  document  for 
open  systems.  It  has  developed  portability  guides  for  transport,  object  management,  and 
X.400  protocols.  It  has  worked  with  the  Corporation  of  Open  Systems  (COS)  Mark  Pro¬ 
gram  and  has  developed  verification  suites  for  portability  guides.  X/Open  organizes  con¬ 
ferences  and  workshops  to  promote  its  concepts.  It  has  organized  its  contributors  into 
working  groups  (User  Console  Program,  System  Vendor,  and  Software  Vendors). 

Results:  X/Open  has  published  portability  guides  for  transport,  object  management,  and 
X.400  protocols. 

Technology  Transfer  Approach  and  Plans:  X/Open  is  making  its  specifications  and  ser¬ 
vices  available  to  companies,  and  is  promoting  its  activities  through  education,  awareness, 
and  training  program. 

Linkages:  X/Open  is  linked  to  the  User  Alliance  for  Open  Systems,  COS,  OSF,  and 
OMG. 


Table  A-25.  X/Open  Matrix 


Technical  Categories 


Business  View 


Information  View 


Technology  View 


Integration 
Fnuneworks  jmd 
Architectures 


Operating  Systems  jind 

Distributed 

Environments 


Communications 


Daui  Miinagement 
Systems 


Application 
Development  Tools 
and  Methods 


Data  Representations 


Infonnation  Modeling 
Tools  iind  Methods 


User  Interface 


Prognimming 

Languages 


Security  Tools  and 
Methods 


Strategic  M^irketing: 
Enable  Euro- vendors 
Some  Control  of 
Unix  Platfonn 
Interfaces  (i,e.,  Unix 
and  Open  Systems) 


Application 

Portability 


POSIX  (XSI) 


OSI  (XTI) 
TCP/IP  (XTI) 
KERMIT 

ANSI  Terminal 
Emulation 


SQL 

ISAM 
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APPENDIX  B.  STANDARDS  AND  TECHNOLOGIES  BRIEFS 


This  appendix  contains  brief  descriptions  of  standards  and  technologies  grouped  by 
the  10  technical  categories: 

•  Integration  Frameworks  and  Architectures:  Overall  integrating  representa¬ 
tions,  models,  and  schemas  of  the  enterprise  and  its  component  parts  (e.g.. 
Application  Portability  Profile  (APP),  Systems  Application  Architecture 
(SAA),  GM-C4  (CAD/CAM/CAE/CIM)  frameworks). 

•  Operating  Systems  and  Distributed  Environments:  Components  used  to 
provide  system  services  (I/O,  process  management,  and  others)  to  applications 
(e.g..  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Unix,  MS-DOS,  NetWare) 

•  Communications:  Components  used  to  connect  applications,  allowing  applica¬ 
tions  to  transfer  data  and  control  among  themselves  (e.g..  Open  Systems  Inter¬ 
connection  (OSI)  and  Transmission  Control  Protocol/Intemet  Protocol 
(TCP/IP)). 

•  Data  Management  Systems:  Components  used  to  store,  manage,  and  retrieve 
data.  Data  management  includes  knowledge  bases,  database  management  sys¬ 
tems  (DBMS),  information  management  systems,  data  dictionaries,  and  schema 
implementations. 

•  Application  Development  Tools  and  Methods:  Tools  and  methods  used  to 
model  and  build  applications  (e.g.,  application  generators). 

•  Data  Representations:  High-level  data  representation  standards  (e.g.,  Stan¬ 
dard  for  the  Exchange  of  Product  Data  (STEP)  and  Electronic  Data  Interchange 
(EDI)). 

•  Information  Modeling  Tools  and  Methods:  Tools  and  methods  used  to  con¬ 
struct  models  of  the  enterprise  and  its  components  (e.g..  Integrated  Computer- 
Aided  Manufacturing  (ICAM)  Definition  Language  (IDEE)  and  Semantic  Uni¬ 
fication  Meta-Model  (SUMM)). 

•  User  Interfaces:  Components  that  allow  users  to  interact  with  the  applications 
making  up  the  integrated  enterprise  (e.g..  Motif  and  X/Windows). 

•  Programming  Languages:  High-level  languages  used  to  represent  algorithms. 
This  category  includes  APPs  (e.g.,  Ada  and  C-i-i-). 


Security  Tools  and  Methods:  Tools  and  methods  used  to  control  access  to 
applications  and  data  (e.g.,  Kerberos). 


B.l  INTEGRATION  FRAMEWORKS  AND  ARCHITECTURES 

Frameworks  and  architectures  apply  the  divide-and-conquer  principle  to  break  up  a 
complex  problem  into  tractable,  logical,  and  interfaced  components.  These  components 
can  then  be  solved  and  integrated  incrementally. 

B.I.I  PORTABLE  COMMON  TOOL  ENVIRONMENT  (PCTE) 

PCTE  started  as  an  ESPRIT  project  in  1 983,  and  grew  into  a  major  initiative  for  the 
definition  and  prototyping  of  a  software  engineering  environment  (SEE)  framework  inter¬ 
face.  PCTE  is  not  an  environment  in  itself,  but  a  framework  or  structure  that  will  be  the 
basis  for  the  construction  of  the  SEE. 

PCTE  focuses  on  data  integration  and  offers  facilities  to  builders  of  large-scale  soft¬ 
ware  environments.  Its  main  areas  of  strength  are  the  repository  definition  and  data  integra¬ 
tion  services.  In  doing  this,  PCTE  aims  at  providing  comprehensive  interface  definitions  for 
data  and  tool  integration,  supporting  multiple  programming  languages,  and  providing  a 
migration  path  for  existing  tools.  It  uses  the  entity-relationship  model  for  some  basic  defi¬ 
nitions,  but  does  not  follow  it  closely.  However,  it  recognizes  data  independence  as  an 
important  means  for  tool  integration  and  for  maintaining  the  separation  between  policy  and 
mechanism. 

The  PCTE  project  is  in  a  fairly  advanced  stage,  with  early  products  already  in  use. 
The  PCTE-i-  project,  which  is  a  PCTE  variant  and  incorporates  some  improvements  over 
PCTE,  is  also  in  an  advanced  stage  of  development. 

B.L2  CAD  FRAMEWORK  INITIATIVE  (CFI) 

CFI  was  established  in  1988  with  the  objective  of  “developing  worldwide  industry 
guidelines  for  electronic  design  automation  tools  and  their  supporting  environments  that 
will  remove  barriers  to  integration.”  It  is  an  international  consortium  of  about  50  corporate 
members. 

CFI  is  working  to  standardize  seven  functional  areas  of  a  framework  environment: 

•  An  Architecture  for  a  framework  that  will  allow  tools  and  framework  compo¬ 
nents  to  be  interoperable  and  interchangeable. 

•  The  Design  Data  Management  task  that  relates  to  the  management  of  design 
information  and  design  meta-data  within  the  framework  environment. 


•  The  Design  Methodology  Management  task  for  specifying  the  representation 
and  execution  of  design  policies. 

•  The  Design  Representation  task  that  relates  to  representation  and  access  of 
CAD  data. 

•  The  Inter-tool  Communication  task  that  builds  guidelines  to  support  both  the 
interoperation  of  applications  and  framework  components  and  the  exchange  of 
control  information  and  data. 

•  The  System  Environment  task  that  develops  guidelines  and  adopts  standards  to 
support  portability,  coexistence,  and  cooperation  of  tools  and  data. 

•  The  User  Interface  task  that  develops  guidelines  for  the  consistent  appearance 
and  behavior  of  the  framework  environment  from  the  user’s  perspective. 

The  1991  CFI  integration  project  exhibited  cooperating  tools  from  30  companies 
that  used  CFI’s  tool  abstraction  specification,  its  inter-tool  communication  mechanism,  and 
its  programming  interface.  The  project  also  demonstrated  the  use  of  its  information  model 
and  programming  interface  for  hierarchical  electrical  net  lists.  The  specifications  and  inter¬ 
faces  are  the  main  products  created  by  CFI  to  date.  Work  on  further  development  is  in 
progress. 

B.1.3  ENGINEERING  INFORMATION  SYSTEM  (EIS) 

The  EIS  program  has  targeted  the  data  interchange  framework  area  with  a  concen¬ 
trated  focus  on  standards  for  electronic  components  and  circuits.  The  EIS  work  has  two 
parts: 

•  The  Integrating  Infrastructure  (IIS),  a  framework  or  integrating  infrastructure 
within  which  product  information  can  be  managed  throughout  the  product  life 
cycle.  The  OS  presents  a  homogeneous  view  of  product  data  that  could  reside 
in  a  heterogeneous  distributed  hardware  environment.  By  providing  this  func¬ 
tionality,  the  IIS  facilitates  integration  of  CAx  (e.g.,  computer-assisted  design 
(CAD),  computer-assisted  manufacturing  (CAM))  tools. 

•  A  pair  of  information  models:  the  engineering  administration  model  and  the 
integrated  circuit  (IC)  CAD  model.  The  former  deals  with  the  services  provided 
by  EIS  (e.g.,  data  exchange,  error  handling,  configuration  management,  tool 
invocation  facilities,  and  communication).  The  IC  CAD  model  is  specific  to  the 


electronic  component  domain  and  addresses  the  design,  layout,  simulation,  and 
testing  of  electronic  circuits  and  ICs. 

EIS  uses  an  object-oriented  approach  in  its  specification  and  implementation. 
Wrappers  (software  encapsulation  techniques)  are  used  to  facilitate  integration  with  exist¬ 
ing  tools,  and  messages  between  system  components  are  used  to  facilitate  communication. 
Popular  standards  and  tools  like  IDEF,  POSIX,  X- Window,  Motif,  Ada,  and  C  are  used 
throughout.  As  a  result,  pieces  of  EIS  work  are  being  used  by  standards  organizations  as 
starting  points. 

The  EIS  program  is  currently  in  its  closing  stages,  with  detailed  specifications 
already  complete.  The  final  phase,  phase  3,  will  develop  a  fully  functional  implementation 
demonstrating  the  EIS  concepts,  guidelines,  and  model. 

B.1.4  GENERAL  MOTORS  CAD/CAM/CAE/CIM  (GM-C4) 

C4  is  a  project  internal  to  the  GM  Corporation  to  develop  a  framework  that  will 
offer  portability  and  interoperability  of  software  applications  through  GM.  Not  much  is 
publicly  known  about  the  project  except  that  it  will  focus  on  open  and  widely  implemented 
standards  to  meet  GM  technical  and  business  requirements. 

B.1.5  INTEGRATED  COMPUTER-AIDED  MANUFACTURING  FACTORY  OF 
THE  FUTURE  (ICAM-FOF) 

The  ICAM-FoF  project  was  initiated  by  the  U.S.  Air  Force  in  1981.  The  FoF  con¬ 
ceptual  framework  is  a  structure  for  understanding  activities  and  information  focusing  on 
factory  management  and  functional  relationships.  It  addresses  important  enterprise  func¬ 
tions  such  as  marketing,  customer  service,  product  engineering,  materials  management, 
production,  logistics,  and  quality  issues.  Related  work  includes  a  FoF  functional  frame¬ 
work,  an  FoF  integration  concept,  and  an  integrated  computer-based  systems  architecture. 

The  FoF  project  has  received  inputs  from  a  wide  range  of  contributing  companies 
and  has  had  its  outputs  used  and  validated  by  many  organizations  as  well.  It  is  thus  a  time- 
tested  guide  for  modernization  activities,  although  it  may  be  lacking  in  state-of-the-art 
thinking. 

B.1.6  AD/CYCLE 

IBM’s  Application  Development  (AD)/Cycle  offers  an  enterprise  modeling 
approach  supported  by  an  integrating  framework  and  a  set  of  application  development 
tools.  The  framework  provides  the  integrating  platform  that  enables  data  sharing  and  coop- 


eration  among  the  tools.  AD/Cycle  conforms  to  the  IBM  System  Application  Architecture 
(SAA)  guidelines.  Parts  of  AD/Cycle  that  were  not  originally  covered  by  SAA,  such  as  the 
programming  interface  to  Repository  Manager,  have  been  added  to  SAA  as  extensions. 

The  AD/Cycle  enterprise  modeling  approach  is  supported  by  tools  that  assist  in  the 
creation,  analysis  and  validation  of  an  enterprise  model,  which  can  then  be  used  to  generate 
applications.  The  enterprise  model  data  and  business  process  requirements  are  centrally 
stored  in  entity-relationship  form  by  the  Repository  Manager.  The  central  control  of  data 
helps  maintain  consistency  of  the  data  and  makes  the  data  available  for  other  tools  in  the 
framework. 

The  architectural  components  of  AD/Cycle  include: 

•  User  Interface;  Implements  the  SAA  Common  User  Access  (CUA)  guidelines. 

•  Workstation  Services:  A  set  of  Presentation  Manager  and  OS/2  services. 

•  Work  Management;  Provides  consistency  in  tool  invocation. 

•  Tool  Services:  Common  functions  required  by  tools  independent  of  where  they 
execute. 

•  AD  Tools:  The  application  development  (AD)  tools  themselves. 

•  AD  Information  Model:  The  specification  of  the  data  that  can  be  shared  by  the 
tools. 

•  Repository  Services:  Centralized  management  of  application  development  data. 

•  Library  Services:  Support  for  application  configuration  control. 

B.1.7  APPLICATION  PORTABILITY  PROFILE  (APP) 

APP,  the  U.S.  Government’s  Open  System  Environment  (OSE)  Profile,  was  pub¬ 
lished  by  the  National  Institute  for  Standards  and  Technology  (NIST)  in  April  1991  (NIST 
Special  Publication  500-187).  The  APP  defines  an  OSE  reference  model  and  set  of  specifi¬ 
cations  (i.e.,  profile)  for  interfaces,  services,  protocols,  and  data  formats  used  within  the  ref¬ 
erence  model.  The  OSE  reference  model  is  composed  of  three  entities  and  two  interface 
components: 

Entities 

•  Application  Software:  Programs,  data,  training,  and  documentation. 
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•  Application  Platform:  The  software  and  hardware  components  that  provide  ser¬ 
vices  to  the  Application  Software. 

•  Platform  External  Environment:  Users,  information  services,  and  communica¬ 
tion  services. 

Interface  Components 

•  Application  Program  Interface  (API):  Connects  the  Application  Software  with 
the  Application  Platform  by  providing  user  interface,  information  interchange, 
communications,  and  internal  system  services. 

•  External  Environment  Interface  (EEI):  Supports  information  transfer  between 
the  Application  Platform  and  the  External  Environment. 

The  APP  profile  specifications  fall  into  seven  categories: 

•  Operating  System  Services 

•  User  Interface  Services 

•  Programming  Services 

•  Data  Management  Services 

•  Data  Interchange  Services 

•  Graphics  Services 

•  Network  Services 

Each  of  the  categories  contains  a  list  of  alternative  specifications  that  can  be  select¬ 
ed  with  an  APP  platform.  For  example,  the  Programming  Services  category  specifies  Ada, 
C,  Cobol,  Fortran,  and  Pascal. 

B.1.8  SYSTEMS  APPLICATION  ARCHITECTURE  (SAA) 

IBM’s  SAA  has  the  goal  of  providing  an  environment  in  which  applications  can  be 
developed  so  they  can  run  consistently  on  various  IBM  computing  platforms  (MVS  for 
System  370,  OS/400  for  AS/400  computers,  and  OS/2  for  PS/2  systems).  A  later  addition 
to  the  family  of  platforms  is  AIX  (IBM’s  version  of  Unix).  The  elements  of  the  SAA  frame¬ 
work  are  Common  User  Access  (CUA),  Common  Programming  Interface  (CPI),  and  Com¬ 
mon  Communications  Support  (CCS). 


CUA  specifies  how  the  system,  including  the  applications,  interacts  with  a  person 
at  a  workstation  or  terminal.  CUA  is  a  set  of  guidelines  that  defines  the  interaction  between 
humans  and  computers.  CCS  controls  the  interconnect  protocols.  It  also  controls  how  sys¬ 
tems  communicate  with  one  another  to  store,  retrieve,  and  move  information  through  the 
communications  network.  CPI  specifies  how  a  programmer  may  write  and  attach  a  new 
application  to  an  SAA  system,  and  defines  a  set  of  application  building  blocks  consisting 
of  languages  and  programming  services  for  application  programmers.  The  Distributed 
Automation  Edition  (DAE)  is  the  mechanism  by  which  the  building  blocks  and  standards 
forming  SAA  are  distributed  to  third-party  software  developers. 

SAA  is  available  on  IBM  systems,  although  there  are  plans  to  extend  it  to  non-IBM 
Unix  systems.  The  platforms  currently  supported  are  IBM  MVS,  VM,  OS/2,  MS-DOS,  and 
IBM  AIX  (a  recent  addition).  IBM’s  strategy  is  to  build  SAA-based  frameworks  that  inte¬ 
grate  application  domains.  Examples  of  frameworks  are  AD/Cycle  for  application  devel¬ 
opment  and  OfficeVision  for  office  systems.  The  Information  Warehouse  is  a  framework 
for  information  access,  and  is  expected  to  become  a  product  by  1996.  Catalogs  of  SAA- 
based  products  in  the  market  can  be  obtained  from  IBM. 

B.1.9  NETWORK  APPLICATIONS  SUPPORT  (NAS) 

NAS  architecture  is  centered  around  the  way  an  application  interacts  with  the  user, 
data,  system,  and  other  applications.  This  view  is  directly  represented  in  the  NAS  architec¬ 
tural  model,  which  Digital  Equipment  Corporation  (DEC)  refers  to  as  the  Application  Inte¬ 
gration  model.  The  model  has  four  components: 

•  Application  Access  Services  used  to  manage  the  user  dialogue. 

•  Information  and  resource  sharing  services  to  handle  the  data  dialogue. 

•  Communications  and  control  services  to  enable  the  application  dialogue. 

•  System  Access  Services  to  carry  the  dialogue  between  the  application  and  the 
operating  system. 

Each  component  of  the  model  is  supported  by  a  set  of  standards  and  standard-based 
products  and  DEC’s  commitment  to  support  different  operating  system  platforms  and  new¬ 
ly  developed  standards. 

NAS  products  are  available  on  DEC  VMS,  Ultrix,  SCO  Unix,  AT&T  Unix  System 
V,  MS-DOS,  IBM  OS/2,  and  Apple  Macintosh  platforms.  Projected  platforms  include 
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IBM’s  AIX  and  OSF/1.  Each  component  in  the  NAS  architecture  is  supported  by  a  set  of 
DEC  products: 

•  Application  Access  Services  are  provided  by  DECwindows,  DECforms, 
LiveLink,  and  BUILDER. 

•  Information/Resource  Sharing  Services  are  supported  by  the  CDA  Toolkit, 
DECImage,  DECPrint,  ALL-IN- 1,  and  others. 

•  Communication  and  Control  Services  products  are  MAILbus  and  DEC/EDl. 

•  System  Access  Services,  including  POSIX. 

B.1.10  NEWWAVE 

Hewlett  Packard’s  (HP)  NewWave  Computing  strategy  is  an  evolutionary  approach 
to  integration.  HP’s  NewWave  architecture  consists  of  the  following: 

•  User  Environment 

•  Application  Environment 

•  Application  Integration  Services 

•  Distributed  System  Services 

•  Software  Development  Environment 

•  Base-level  Systems  and  Networks 

The  evolutionary  approach  to  integration  is  reflected  by  NewWave  products  such  as 
the  NewWave  desktop,  HP-Sockets,  and  VUE.  Of  particular  interest  is  VUE,  which  allows 
existing  applications  to  be  integrated  at  the  user  interface  and  application  data  interchange 
level. 

HP’s  NewWave  products  are  available  in  MS-DOS,  OS/2,  Macintosh,  HP-UX, 
SunOS,  SCO  Unix,  IBM  AIX,  and  DEC  Ultrix  platforms;  products  for  OSF/1  are  currently 
being  planned.  A  feature  of  the  NewWave  desktop  is  its  availability  for  Windows  3.0  plat¬ 
forms.  Other  noteworthy  NewWave  products  are  the  HP-Sockets,  a  set  of  12  access  rou¬ 
tines  that  can  be  used  to  build  user  interfaces  that  integrate  applications  running  on  HP-UX 
and  MPE  XL  platforms;  and  VUE,  a  graphical  user  interface  shell  that  can  run  on  several 
platforms. 


Historically,  products  based  on  the  commercial  architectures  have  been  available 
for  NAS  and  SAA  systems  since  1988.  HP  NewWave  products  became  available  after  HP’s 
announcement  of  the  NewWave  strategy  in  1990. 


B.2  OPERATING  SYSTEMS  AND  DISTRIBUTED  ENVIRONMENTS 

Operating  systems  are  defined  as  those  components  that  provide  system  services 
(I/O,  process  management,  and  others)  of  a  computer  to  applications.  Distributed  environ¬ 
ments  are  those  capabilities  which  extend  operating  systems,  more  or  less  transparently, 
across  many  physically  dispersed  computers. 

B.2.I  PORTABLE  OPERATING  SYSTEM  INTERFACE  FOR  COMMON 
ENVIROMENTS  (POSIX) 

POSIX  is  the  IEEE-initiated  effort  to  develop  a  standard  for  operating  systems.  It 
draws  much  of  its  technical  basis  from  Unix.  A  major  trend  in  operating  systems  is  conver¬ 
gence  towards  POSIX  compliancy.  Real-time  extensions  are  becoming  increasingly  impor¬ 
tant,  particularly  in  the  areas  of  manufacturing,  and  POSIX  is  addressing  these. 

B.2.2  OSF/1 

OSF/1  is  the  Open  Software  Foundation’s  standard  for  operating  systems.  It  is 
based  on  Unix,  is  designed  to  support  OSF’s  Distributed  Computing  Environment  (DCE), 
and  claims  POSIX  compliance.  OSF/1  also  draws  upon  the  Mach  operating  system  work 
done  at  Camegie-Mellon  University,  providing  real-time  and  multi-processing  support. 

B.2.3  SYSTEM  V  RELEASE  4  UNIX  (SVR4) 

SVR4  is  AT&T’s  commercial  version  of  Unix,  and  is  well-established  in  the  mar¬ 
ketplace.  It  is  also  the  operating  system  sanctioned  and  supported  by  the  Unix  International 
(UI)  consortium  (the  competitive  alliance  to  OSF).  SVR4  is  the  choice  for  supporting  UI’s 
Atlas  distributed  environment.  SVR4  also  claims  POSIX  compliance. 

B.2.4  MICROSOFT  DISK  OPERATING  SYSTEM  (MS-DOS) 

MS-DOS  is  the  principal  operating  system  used  for  personal  computers.  MS-DOS 
has  an  overwhelmingly  large  installed  base  and  the  recent  release  of  5.1  functionality  con¬ 
tinues  its  effective  evolution.  MS-DOS  is  limited  in  many  ways  compared  to  the  Unix-type 
operating  systems.  Transparently  positioning  MS-DOS  in  an  integrated  environment  pre¬ 
sents  many  challenges,  though  it  also  appears  many  third-parties  are  willing  to  accept  that 
challenge. 

B.2.5  OS/2 

OS/2  is  IBM’s  multi-tasking  operating  system,  designed  to  overcome  MS-DOS 
type  limitations,  for  use  on  personal  computers.  In  many  ways,  it  brings  Unix-class  features 


to  MS-DOS  oriented  users.  Yet  the  future  of  OS/2  is  uncertain.  IBM  claims  commitment  to 
it  but  adds  that  there  are  other  very  good  32-bit  technologies  out  there,  i.e.,  AIX,  AS/400. 
Meanwhile  Microsoft,  IBM’s  ex-partner  in  OS/2  development,  continues  pushing  Win¬ 
dows  NT  (an  OS/2  competitor). 

B.2.6  MAC  SYSTEM  7 

The  Mac  System  7  greatly  extends  the  services  offered  by  the  Apple  Macintosh 
family  of  personal  computers,  particularly  in  the  areas  of  distributed  file  management,  data¬ 
base  management,  and  interprocess  communication.  Although  it  is  proprietary,  it  is  an 
important  development  because  of  Apple’s  installed  base.  It  is  also  relatively  inexpensive. 

B.2.7  OBJECT  MANAGEMENT  GROUP  (OMG) 

OMG  has  started  a  major  effort  to  standardize  interfaces  for  distributed  objects. 
Though  intended  for  software  portability  and  reusability,  the  principles  are  drawn  from  and 
are  applicable  to  distributed  computing.  The  effort  is  producing  the  Object  Management 
Architecture,  with  the  Object  Request  Broker  (ORB)  as  its  central  element.  An  announce¬ 
ment  of  the  specification  is  expected  momentarily,  and  the  specification  will  be  made  public 
within  a  year.  Although  its  own  members  intend  to  pursue  object-oriented  projects,  OMG’s 
work  is  expected  to  play  a  major  role  in  the  future  specification  of  distributed  systems. 

B.2.8  OPEN  DISTRIBUTED  PROCESSING  (ODP) 

The  ODP  effort,  sponsored  by  the  International  Organization  for  Standardization 
(ISO),  began  in  1987  to  produce  a  reference  model  for  distributed  processing.  This  model 
will  form  the  basis  for  distributed  processing  standards  which  will  allow  compliant  appli¬ 
cations  to  communicate  in  a  transparent  manner. 

ODP  work  is  progressing  along  three  fronts.  The  first  of  these  is  the  development 
of  the  reference  model.  The  model  is  being  used  as  the  basis  for  a  prototype  ODP  system 
called  the  Advanced  Network  Systems  Architecture  (ANSA).  Thirdly,  a  consortium 
(ODPC)  is  being  set  up  to  provide  the  testing  infrastructure  needed  to  support  products. 

B.2.9  DISTRIBUTED  COMPUTING  ENVIRONMENT  (DCE) 

DCE  is  expected  to  be  available  for  release  in  the  fourth  quarter  of  1991.  DCE  is 
composed  of  existing  products,  and  is  intended  to  support  international  standards  where 
applicable.  It  provides  an  open  architecture  that  has  extensibility  built  in.  DCE  is  generally 
thought  to  be  an  important  development  in  distributed  computing,  though  products  are  not 


expected  for  at  least  a  year.  Somewhat  surprisingly,  UI  has  pledged  to  integrate  it  into  its 
own  distributed  computing  environment.  Atlas. 

B.2.10  OBJECT-ORIENTED,  CHANGE-ORIENTED  REFERENCE  ENVIRON¬ 
MENT  (OO-CORE) 

OO-CORE  draws  on  the  concepts  of  the  ANSI  SPARC  three-schema  architecture, 
database  management,  and  CIM-OSA  to  create  a  tool  that  supports  migration  to  an  object- 
oriented  system  from  legacy  systems.  It  uses  EXPRESS  for  object  specification  and  a  dia¬ 
lect  of  SQL,  called  00- SQL,  for  object  access  and  management.  OO-CORE  directly 
addresses  the  problem  of  change,  something  other  frameworks  and  environments  seldom 
do. 

B.2.11  PROCESS-ORIENTED  MANAGEMENT  SYSTEM  (POMS) 

POMS  is  developed  by  Incode,  Inc.,  Reston,  Virginia,  for  IBM.  It  functions 
between  the  planning  or  scheduling  system  and  plant  floor  supervisory  control  by  imple¬ 
menting  higher-level  instructions,  retrieving  recipes,  and  monitoring  the  status  of  shop 
floor  operations. 

B.2.12  ANSAWARE 

ANSAWare,  based  on  the  Open  Systems  Interconnection  (OSI)  Open  Distributed 
Processing  (ODP),  gives  the  user  the  environment  and  facilities  to  create  distributed  pro¬ 
cesses.  While  ANSAWare  is  still  a  development  effort,  it  is  available  for  purchase  from 
ISA.  Atypically,  the  prototype  is  far  ahead  of  the  standard.  It  is  unclear  at  this  point  how 
applicable  ANSAWare  will  be  to  enterprise  integration,  but  it  bears  watching. 

B.2.13  CIMPLICITY 

Cimplicity  Systems  is  a  collection  of  factory-floor  monitoring  and  control  products 
for  use  with  different  standard  computers  and  operating  systems.  Cimplicity  gives  factory 
personnel  a  window  into  the  manufacturing  process,  providing  timely  information  about 
factory  conditions.  It  lets  users  easily  expand  or  modify  their  systems,  preserving  their  ini¬ 
tial  investment  in  computers  and  training,  and  reducing  costs  associated  with  new  computer 
platforms. 

The  software  operates  with  IBM-type  personal  computers  using  Interactive  Sys¬ 
tems  Unix,  dec’s  VAXA^MS  and  Ultrix  computer  platforms,  and  Hewlett-Packard  (HP- 
UX)  based  systems.  It  provides  a  system  architecture  that  takes  data  collected  from  control- 
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lers  and  dynamically  knits  them  together  into  a  global  database  across  computers  in  the  net¬ 
work.  Application  modules  access  this  global  database,  providing  graphic  status 
monitoring,  alarm  management,  and  Statistical  Process  Control  (SPC). 

Much  of  the  original  Cimplicity  development  was  done  on  Digital’s  VMS  operating 
system,  using  a  GE  Fanuc-developed  application  environment  to  insulate  the  application 
modules  from  the  operating  system. 

B.2.14  DISTRIBUTED  OBJECT  MANAGEMENT  FACILITY  (DOME) 

The  NewWave  distributed  application  integration  architecture  has  as  one  of  its  com¬ 
ponents  a  distributed  computing  facility  known  as  DOME.  It  contains  many  functions  one 
would  require  from  any  distributed  computing  environment.  It  currently  runs  under 
Microsoft  Windows,  and  is  scheduled  to  mn  under  OS/2  and  Unix  as  well. 

B.2,I5  OBJECT  LINKING  AND  EMBEDDING  (OLE) 

Microsoft  has  an  application  environment  solution  called  Object  Linking  and 
Embedding  (OLE)  that  provides  a  first  step  toward  an  object-oriented  distributed  environ¬ 
ment.  It  extends  the  Dynamic  Data  Exchange  (DDE)  protocols  that  allow  one  to  use  and, 
to  some  extent,  manage  dissimilar  objects.  Currently,  it  does  not  run  over  a  network.  It  is 
expected  that  Microsoft  will  expand  and  refine  OLE  and  target  it  for  Windows,  Presentation 
Manager,  and  Microsoft  environments.  A  number  of  applications  are  either  implemented, 
being  implemented,  or  are  targeted  for  OLE,  including  Lotus  1-2-3  and  NewWave.  As  a 
platform  integration  tool,  OLE  deserves  to  be  considered. 

B.2.16  NETWARE 

Novell’s  NetWare,  a  personal  computer-local  area  network  (PC/LAN)  operating 
system,  clearly  dominates  the  market  with  over  50%  of  the  market  share,  and  there  is  every 
reason  to  believe  that  this  dominance  will  continue.  Novell  is  famous  for  its  foresight,  infra¬ 
structure,  distribution  channels,  and  aggressive  marketing.  It  continues  to  lead  in  the  impor¬ 
tant  area  of  connectivity.  It  recently  announced  a  product  shipment  that  was  the  result  of  a 
joint  venture  with  Sequent  Computer  Systems.  This  product  allows  NetWare  to  increase  its 
scale  of  services,  as  it  can  handle  up  to  1,000  users  of  a  relational  database  management 
system  (DBMS). 


B.2.17  LAN  MANAGER 

The  LANManager,  a  PC-LAN  operating  system,  has  a  fraction  of  the  PC-LAN  mar¬ 
ket  share.  It  is  being  considered  because  it  was  backed  at  one  time  or  another  by  Microsoft, 
IBM,  3Com,  and  AT&T.  Almost  simultaneously,  3Com  and  Microsoft  parted  ways,  and 
IBM  announced  it  would  market  NetWare.  However,  Microsoft  announced  in  October 
1991  that  it  would  release  a  new  version  of  LANManager  (version  2.1)  and  associated 
products  that  will  increase  its  connectivity.  Added  features  would  include  Transmission 
Control  Protocol/Internet  Protocol  (TCP/IP)  support,  full  integration  into  Windows, 
increased  interoperability  with  Novell’s  NetWare,  and  support  for  Apple’s  Macintosh  as 
LANManager  client.  These  enhancements  are  consistent  with  Microsoft’s  strategic  shift  to 
gain  added  acceptance  via  Windows  (and  consequently  a  decreased  emphasis  on  OS/2)  and 
greater  connectivity. 

B.2.18  VINES 

Banyan’s  Vines  PC-LAN  operating  system  is  also  increasing  its  connectivity.  Ban¬ 
yan  has  recently  announced  an  agreement  with  Digital  Communication  Associates  to  mar¬ 
ket  Vines  jointly  in  order  to  provide  SNA  connectivity.  Additionally,  it  will  seek  out  IS  Vs 
to  add  value  to  Vines,  releasing  APIs  to  expedite  application  development.  SCO  Unix  and 
Banyan  recently  announced  a  joint  venture  to  port  Vines  services  to  SCO  Unix. 
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B.3  COMMUNICATIONS 

Communication  protocols  and  profiles  that  support  open  systems  communications 
are  dominated  by  TCP/IP  and  OSI.  Although  they  are  usually  compared,  their  respective 
scopes  are  very  different,  so  comparisons  can  be  misleading. 

B.3.1  TRANSMISSION  CONTROL  PROTOCOL/INTERNET  PROTOCOL 

(TCP/IP) 

TCP/IP  is  by  far  the  more  popular  of  the  two  protocol  suites  in  the  United  States.  It 
is  the  de  facto  networking  standard,  with  huge  installation  base.  Any  enterprise  integration 
solution  must  consider  TCP/IP. 

Strictly  speaking,  TCP/IP  is  the  name  of  two  key  networking  protocols.  Over  the 
years,  TCP/IP  has  come  to  more  broadly  refer  to  a  suite  of  protocols  that  together  provide 
full-scale  networking  capabilities.  Originally  developed  for  the  ARPANET,  TCP/IP  was 
released  into  the  public  domain  and  quickly  adopted  by  U.S.  research  community.  Though 
somewhat  lacking  features  compared  to  OSI  protocol  suites,  TCP/IP  has  the  broad-based 
implementation  experience  and  flexibility  that  supports  continued  growth. 

B.3.2  MANUFACTURING  AUTOMATION  PROTOCOL/TECHNICAL  AND 
OFFICE  PROTOCOL  (MAP/TOP) 

MAP  and  TOP  are  profiles  of  OSI  standards  which  define  networking  for  manufac¬ 
turing  and  office  environments,  respectively.  They  are  very  similar  to  each  other,  and  are 
designed  to  interoperate  with  other  OSI-type  networks  quite  easily.  Though  more  function¬ 
al,  they  have  not  overcome  the  wake  of  TCP/IP’s  popularity. 

B.3.3  GOVERNMENT  OPEN  SYSTEMS  INTERCONNECTION  PROFILE 
(GOSIP) 

GOSIP  is  an  OSI  networking  profile  promoted  by  the  U.S.  Government  for  use  in 
its  procurements.  Whereas  TCP/IP  addresses  internetworking  and  data  transmission,  GOS¬ 
IP  addresses  a  larger  picture  (e.g.,  dialogue  control,  representation)  and,  consequently, 
brings  with  it  more  complexity  and  overhead.  Again,  it  remains  to  be  seen  how  the  evolu¬ 
tion  of  TCP/IP  and  OSI-type  profiles  such  as  GOSIP  will  converge  or  diverge. 

B.3.4  TRANSPARENT  FILE  ACCESS  (TFA) 

TEA  is  an  IEEE-sponsored  development  to  create  a  standard  for  transparent  file 
management  and  transmission,  independent  of  knowledge  of  specific  file  transfer  services 
or  mechanisms.  It  is  a  goal  of  TFA  to  express  the  semantics  of  file  systems  such  as  Network 


File  System  (NFS),  RFS,  AFS,  Network  Computing  System  (NCS),  in  a  standard  manner. 
TFA  is  also  known  as  the  IEEE  POSEX  committee  P1003.8,  and  is  a  component  of  the  NIST 
APR 

B.3.5  NETWORK  COMPUTING  SYSTEM/REMOTE  PROCEDURE  CALL 
(NCS/RPC) 

NCS/RPC  are  the  distributed  file  management  and  remote  procedure  mechanisms 
included  in  the  OSF’s  DCE.  They  are  also  called  out  as  components  of  the  NIST  APR  This 
system  (developed  by  HR/ Apollo)  is  the  prime  competitor  of  the  popular  NFS  system  from 
Sun. 

B.3.6  GOVERNMENT  NETWORK  MANAGEMENT  PROFILE  (GNMP) 

GNMP  is  a  still  developing  profile  created  under  the  auspices  of  the  NIST.  Intended 
to  be  similar  in  style  and  applicability  to  GOSIP,  it  addresses  areas  related  to  network  man¬ 
agement.  GNMP  is  included  as  part  of  the  APR 

B.3.7  X.500 

X.5()0  refers  to  the  large  set  of  standards  which  have  been  developed  to  define  the 
operation  of  directory  services  for  use  in  an  OS  I  environment.  Interestingly,  a  major 
TCP/IP-based  facility,  NYSERNet  in  the  eastern  United  States,  is  developing  an  X.500- 
based  system  for  its  TCP/IP  environment.  It  appears  that  X.500  will  continue  to  gain  accep¬ 
tance  in  serving  as  a  common  element  across  different  communications  environments. 
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DATA  MANAGEMENT  SYSTEMS 


Data  management  systems  are  those  software  components  used  to  manage  the  stor¬ 
age  and  retrieval  of  data.  Technologies  included  are  DBMSs,  data  dictionary  systems,  and 
other  information  management  technologies  such  as  hypertext  and  hypermedia.  Standard¬ 
ization  efforts  underway  are  directed  towards  issues  of  data  management  in  heterogeneous 
distributed  environments,  data  dictionaries,  and  object-oriented  data  management  systems. 

B.4.1  INFORMATION  RESOURCE  DICTIONARY  SYSTEM  I  (IRDSI) 

The  first  IRDS  standard  (ANSI  X3H4)  is  based  on  the  relational  model.  It  is  intend¬ 
ed  to  provide  a  framework  that  defines  the  information  that  will  be  captured  and  maintained 
by  an  Information  Resource  Dictionary  (IRD).  The  IRDS  Framework  identifies  the  enter¬ 
prise  data,  hardware,  interfaces,  and  the  services  provided  by  the  enterprise  processing 
facilities. 


B.4.2  INFORMATION  RESOURCE  DICTIONARY  SYSTEM  2  (IRDS2) 

A  second  IRDS  (ANSI  X3H4  and  ISO)  is  under  consideration.  IRDS2  will  extend 
the  ANSI  IRDS  1  standard  and  be  based  on  object-oriented  concepts.  A  core  object  model 
will  support  generic  base  services,  upon  which  IRDS2  service  profiles  and  content  modules 
will  be  implemented.  Together,  the  set  of  content  modules  for  an  IRDS  system  defines  the 
information  model  for  an  enterprise. 

B.4.3  REMOTE  DATABASE  ACCESS  (RDA)  PROTOCOL 

RDA  Protocol  standard  has  been  developed  to  enable  interoperability  of  database 
management  systems.  It  is  expected  to  become  a  full  ISO  standard  by  the  end  of  1 99 1 .  RDA 
is  a  mechanism  to  enable  the  operation  of  distributed  databases  and  their  access. 

B.4.4  SQL 

SQL  is  a  relational  database  query  language  developed  at  IBM  in  the  mid-1970s. 
SQL  has  been  available  in  IBM  products.  System  R  and  DB2,  since  the  late  1970s.  The  use¬ 
fulness  of  the  language  was  recognized  early  on;  non-IBM  SQL  products  were  actually 
available  before  IBM  formally  released  its  SQL  based  products.  The  ANSI  X3H2  Database 
Committee  produced  the  standard  for  SQL  in  the  mid-1980s. 

B.4.5  OBJECT-ORIENTED  SQL 

The  OO-CORE  project  at  IBM  requires  the  use  of  an  object-oriented  data  manipu¬ 
lation  language  (DML)  and  a  language  for  data  definition.  The  data  manipulation  language 
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(DML)  for  OO-CORE,  00-SQL,  is  based  on  the  SQL  paradigm.  The  data  definition  lan¬ 
guage  used  by  OO-CORE  is  EXPRESS.  Once  objects  are  defined  in  EXPRESS,  they  are 
edited  by  using  00-SQL  data  definition  commands.  Still,  OO-CORE  objects  are  not  bound 
a  relational  database  model  (but  neither  do  they  preclude  it). 

It  is  the  intent  of  OO-SQL  to  provide  a  language  that  adapts  to  the  CIM-OSA  3x3x4 
“cube”  model,  yet  is  simple  to  use  and  understand. 

B.4.6  HYPERMEDIA 

While  the  vision  of  hypermedia  has  been  in  existence  since  the  1950s,  standards 
support  (such  as  HyTime,  ISO/IEC  DIS  10744)  has  just  recently  begun  to  appear.  The 
vision  of  hypertext  is  to  put  information  on-line  and  build  links  between  associated  infor¬ 
mation,  regardless  of  platform  or  physical  location.  Once  these  links  are  in  place,  the  very 
simple  and  primitive  human  gesture  of  pointing  will  allow  users  to  access  information 
quickly.  Notecards  (by  Xerox)  and  Augment  (by  Engelbart)  have  existed  as  commercial 
products  for  quite  some  time,  but  with  serious  limitations  that  have  prevented  their  wide¬ 
spread  use.  Several  hypermedia  environments  (such  as  HyperBase  and  Guide)  exist  for  the 
PC,  and  many  PC  programs  use  hypertext  systems  for  on-line  help. 

B.4.7  COMMON  DATA  MODEL  (CDM) 

CDM  is  part  of  the  Integrated  Information  Support  System  (IISS).  The  CDM  is  the 
data  dictionary  used  to  provide  uniform  access  to  the  databases  in  the  system.  The  IISS 
project,  sponsored  by  the  U.S.  Air  Force,  began  in  1978.  The  goal  of  the  project  was  to 
implement  a  system  based  on  the  then-new  Three  Schema  Architecture  for  databases 
(ANSI  1977),  and  show  its  applicability  to  the  problems  associated  with  the  manufacturing 
of  large  weapon  systems.  The  project  was  restricted  to  developing  large  distributed  heter¬ 
ogeneous  databases  so  they  complied  with  the  standards  existing  at  the  time  for  databases 
(ANSI  Three  Schema  Architecture  and  draft  SQL). 

There  is  a  prototype  IISS  CDM  system  in  existence,  implemented  on  VAX  VMS 
and  IBM  MVS  systems.  The  system  includes  a  data  definition  language  (NDDL  or  Neutral 
Data  Definition  Language)  used  to  create  the  Common  Data  Model,  and  a  data  manipula¬ 
tion  language  (NDML  or  Neutral  Data  Manipulation  Language)  used  to  access  the  data. 
There  are  no  efforts  being  made  to  standardize  or  make  products  from  the  IISS  components, 
although  the  IISS  program  has  conducted  studies  to  develop  a  system  based  on  current 
database  standards. 


B.5  APPLICATION  DEVELOPMENT  TOOLS  AND  METHODS 

Application  Development  Tools  and  Methodologies  are  those  tools  and  techniques 
used  to  improve  programmer  productivity,  and  technologies  that  contribute  to  the  develop¬ 
ment  of  applications.  These  include  application  generators,  graphical  user  interface  build¬ 
ers,  standard  communication  libraries  and  application  profiles,  and  application 
development  environments.  We  include  in  this  category  the  technologies  developed  in  the 
field  of  artificial  intelligence. 

B.5.1  X/OPEN  AND  POSIX  APIS 

The  Application  Protocol  Interfaces  (APIs)  developed  by  the  X/Open  Consortium 
and  the  incipient  IEEE  POSIX  Application  Environment  Profiles  (AEPs)  (POSIX  1003.4, 
1003.10,  1003.12,  1003.13,  1003.14,  1238,  and  1238.1)  are  notable  efforts  at  providing  a 
standard  library  and  interface  for  applications  programming.  Standard  communications 
libraries  and  application  environment  profiles  define  interfaces  to  access  different  commu¬ 
nications  protocols  and  effectively  free  the  software  developer  from  the  burden  of  develop¬ 
ing  the  communications  software  needed  to  interface  an  application  with  other  applications 
and  systems,  while  adding  the  benefit  of  portability,  interoperability,  and  scalability  of 
application  software. 

B.5.2  INTEGRATED  DESIGN  SUPPORT  SYSTEM  (IDS) 

IDS  is  a  multiphase  research  initiative  sponsored  by  the  US  Air  Force  to  develop  an 
architecture  for  the  use  and  distribution  of  digital  data.  Phase  I  of  the  program  (1984-1988) 
demonstrated  an  integrated  technical  information  system  capable  of  capturing,  and  manag¬ 
ing  distributed  digital  data  across  the  entire  life  cycle  of  a  major  Air  Force  weapon  system. 

IDS  focuses  on  three  concepts:  the  application  of  a  data-driven  approach;  optimal 
use  of  existing  assets;  and  the  implementation  of  prototype  development  techniques.  The 
data-driven  approach  uses  the  three-schema  architecture  as  a  base  concept  and  defines  user, 
enterprise,  and  computer  system  views  of  the  data.  The  user  views  are  represented  by  IDEF 
function  models.  The  enterprise  view  is  a  logical  view  of  the  product  data  required  as 
defined  in  the  IDS  Product  Data  Conceptual  Model  (PDCM).  The  computer  systems’  view 
is  the  software,  hardware,  data  support  systems,  and  assets  require  to  implement  an  IDS 
system. 


B.5.3  KNOWLEDGE-BASED  SYSTEMS  (KBS) 

The  most  significant  use  of  KBS  technology  to  date  has  been  in  diagnosis.  Thou¬ 
sands  of  diagnostic  systems  are  in  use  today.  Some  diagnostic  systems  are  built  by  having 
a  knowledge  engineer  interview  a  domain  expert  on  the  problems  in  the  domain  and  how 
they  are  diagnosed.  The  expert’s  knowledge  is  then  encoded  typically  in  if-then  rules. 
Another  form  of  diagnosis  is  called  Model  Based  Reasoning  (MBR).  MBR  systems  work 
by  producing  a  simulation  of  the  domain  of  interest  and  using  knowledge  to  diagnose  fail¬ 
ures  by  breaking  the  model  in  a  way  that  reflects  observed  symptoms. 

To  a  lesser  extent,  KBSs  are  used  in  planning.  Applications  ranging  from  job  shop 
scheduling  to  planning  movements  of  the  Pacific  Fleet.  Planning  systems  accept  from  users 
desired  goals,  operations  which  can  be  performed,  and  a  set  of  constraints.  The  planner  then 
generates  a  set  of  operations  that  when  executed  will  achieve  the  goals  without  violating 
any  of  the  constraints. 

B.5.4  APPLICATION  GENERATORS 

Application  generators  have  been  in  use  for  several  years.  The  best  results  have 
been  obtained  in  the  business  data  processing  field,  where  commonplace  input/output 
requirements  can  be  abstracted  and  met  by  simple  high-level  instructions  or  recipes.  Sev¬ 
eral  of  the  application  generators  currently  on  the  market  can  be  driven  directly  from  a  data 
dictionary  generated  by  a  CASE  (computer-assisted  software  engineering)  tool.  Graphical 
user  interface  builders  allow  the  programmer  to  design  and  build  a  graphical  user  interface 
interactively.  They  are  typically  menu  driven  and  can  cut  the  user  interface  development 
time  significantly.  The  principal  limitation  of  application  generators  is  their  inability  to  han¬ 
dle  complex  non-routine  requirements  for  special-purpose  applications. 

B.5.5  PLANTWORKS 

IBM  PlantWorks  helps  non-programmers  devise  and  operate  cell  control  programs 
at  the  supervisory  level  quickly  via  graphical,  icon-driven,  programming  techniques.  Writ¬ 
ten  for  IBM  by  Measurex  Automation  Systems  (Cupertino,  CA)  to  work  on  S  AA  platforms. 
Released  in  1988. 

B.5.6  NEURAL  NET 

Neural  networks  are  made  up  of  many  simple,  highly  interconnected  processing 
elements  that  dynamically  interact  with  each  other.  The  system  as  a  whole,  not  any  single 
element,  learns  and  respond  to  information.  Neural  nets  can  discover  complex  relationships 
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among  data  and  predict  trends  based  on  this  data.  Unlike  KBSs,  in  which  the  developer  sup¬ 
plies  the  rules,  many  neural  nets  learn  from  the  data  they  process. 

B.5.7  SOURCE-CODE  CONTROL  SYSTEM  (SCCS) 

sees  is  used  to  manage  and  control  various  versions  of  machine-readable  text 
including  program  source  code,  documentation,  and  libraries,  throughout  the  life  cycle  of 
each.  fYovided  with  most  Unix-type  systems,  SCCS  is  a  regularly  used  tool  of  software 
developers.  X/Open  and  the  NIST  APP  include  this  technology  in  their  profiles. 
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B.6  DATA  REPRESENTATIONS 

Data  representation  and  exchange  technologies  and  standards  are  the  focus  of  some 
of  the  most  vigorous  standards  activities.  The  ability  to  depict,  understand,  and  exchange 
complex  structured  data  between  heterogenous  systems  is  an  important  requirement  of  a 
geographically  dispersed  but  information-integrated  enterprise.  The  most  important  bene¬ 
fits  derived  from  this  technology  are  hardware  and  software  independence  (thus  providing 
users  the  choice,  for  example,  of  the  most  suitable  CAD/GAM  system  for  the  task),  and  the 
fact  that  only  a  few  data  translators  (pre-  and  post-processors)  are  needed. 

B.6.1  STANDARD  FOR  THE  EXCHANGE  OF  PRODUCT  DATA  (STEP) 

STEP  is  an  international  (ISO)  effort  that  brings  together  a  number  of  national 
efforts  to  build  an  engineering  data  exchange  specification.  This  specification  includes 
complete  product  definition  information  as  well  as  related  life  cycle  data  for  a  part  or  sub- 
assembly,  be  it  mechanical,  electrical,  or  electronic. 

At  this  time,  STEP  is  in  its  infancy.  A  large  amount  of  standards  activity  is  in 
progress,  with  the  IGES-PDES  Organization  (IPO)  meeting  every  quarter.  STEP  will  make 
extensive  use  of  EXPRESS,  an  object-oriented  language  defined  in  STEP  Part  1 1 . 
EXPRESS  has  the  potential  to  be  used  in  many  information  modeling  and  integration  con¬ 
texts.  Although  young,  STEP  will  have  profound  impact  on  any  enterprise-wide  informa¬ 
tion  modeling  and  integration  effort. 

B.6.2  ELECTRONIC  DATA  INTERCHANGE  (EDI) 

The  ANSI  ASC  X12  group  of  standards  for  Electronic  Data  Interchange  provides 
for  exchange  of  business  documents  and  forms  such  as  purchase  and  change  orders,  invoic¬ 
es,  and  shipping  notices.  The  X12  series  is  comprised  of  two  sets  of  standards:  foundation 
standards  (like  the  Data  Element  Dictionary,  XI  2.3)  that  specify  common  aspects  of  busi¬ 
ness  data  interchange  and  transaction  set  standards  that  are  specific  to  the  nature  of  docu¬ 
ments  being  transferred  (for  instance,  purchase  orders)  or  transactions  performed. 

Many  companies  are  already  using  EDI  in  some  form,  often  encapsulating  it  in  elec¬ 
tronic  mail  messages.  Thus  it  is  not  surprising  that  Electronic  Data  Interchange  for  Admin¬ 
istration  (EDIFACT)  and  CCITT  X.400  (among  others)  are  coordinating  their  activities  to 
ensure  future  compatibility. 

Presently  the  need  for  translating  EDI  data  into  data  compatible  with  legacy  sys¬ 
tems  is  met  by  gateway  services  provided  by  value-added  networks  run  by  GE,  AT&T, 


IBM,  BT  Tymnet,  and  others.  Some  software  vendors  also  provide  translation  software  for 
such  purposes. 

The  X 12  set  of  standards  will  play  a  major  role  in  any  broad  El-related  project.  They 
are  especially  critical  to  organizations  that  are  seeking  to  improve  operations  by  instituting 
JIT  methods  or  those  that  have  a  large  number  of  trading  partners. 

EDI  standards  often  face  incompatibilities  due  to  differences  in  their  data  dictionar¬ 
ies.  There  is  a  fair  amount  of  work  in  progress  not  only  to  remove  such  incompatibilities, 
but  also  to  evolve  new  standards  and  to  define  an  “Open  EDI  Model”  for  the  identification 
and  coordination  of  existing  and  future  standards  and  services. 

B.6.3  INITIAL  GRAPHICS  EXCHANGE  SPECIFICATION  (IGES) 

IGES  applies  to  product  data  interchange.  It  covers  drawings,  documentation,  and 
other  manufacturing-related  information  such  as  tolerances,  form  features,  and  material 
properties.  IGES  has  traditionally  been  used  to  exchange  data  between  CAD/CAM  and 
finite  element  analysis  systems.  IGES  does  not  cover  the  complete  product  life-cycle  or 
specify  manufacturing  processes  for  the  parts  it  describes  or  their  relationships. 

IGES  is  widely  specified  in  the  U.S.  as  an  ANSI  standard  (Y  14.29- 1989),  a  planned 
FIPS  PUB,  and  as  part  of  CALS  with  many  implementations  that  are  commercially  avail¬ 
able.  The  IPO  has  an  aggressive  IGES  program  and  has  just  announced  the  release  of  IGES 
5.1. 


Although  IGES  defines  representations  for  engineering  data,  it  does  not  specify  oth¬ 
er  components  such  as  user  interfaces  and  machine-machine  interfaces.  At  times,  this 
weakness  has  led  to  incompatibilities  between  systems  claiming  IGES  compliance.  The 
fact  that  there  is  no  conformance  testing  for  IGES  aggravates  the  problem. 

B.6.4  COMPUTER  GRAPHICS  METAFILE  (CGM) 

CGM  is  a  file  format  to  define  any  kind  of  picture  or  drawing.  It  is  independent  of 
device  requirements  and  translatable  into  the  native  formats  of  specific  hardware.  CGM  is 
a  FIPS  PUB  (128)  and  a  part  of  CALS.  Many  CGM  implementations  for  different  platforms 
are  available. 
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STANDARD  GENERALIZED  MARKUP  LANGUAGE  (SGML) 


SGML  is  a  standard  that  defines  language  and  grammar  for  document  markup,  sep¬ 
arating  document. structure  from  presentation.  It  specifies  the  required  and  permitted  set  of 
markups  for  documents  and  states  how  they  are  distinguished  from  text. 

As  a  technology  SGML  is  fairly  stable.  However,  there  is  lack  of  consensus  in 
deciding  on  the  particular  markup  to  be  used  for  different  kinds  of  documents.  Several 
products  are  beginning  to  become  available,  including  parsers,  structured  document  prep¬ 
aration  environments  (e.g.,  ArborText),  and  electronic  book  interfaces  (e.g.,  DynaBook). 

B.6.6  RASTER  EORMAT 

Raster  Format  refers  to  the  data  representation  format  defined  in  military  standard 
28002.  This  standard  is  part  of  the  CALS  profile  of  standards.  MIL-R-28002  identifies  the 
requirements  to  be  met  when  raster  graphics  data  represented  in  digital,  binary  format  are 
delivered  to  the  Government. 

B.6.7  OPEN  DOCUMENT  ARCHITECTURE/INTERCHANGE  FORMAT/- 
LANGUAGE  (ODA/ODIF/ODL) 

ODA  is  a  means  to  achieve  complete  interchangeability  (among  applications  on  dif¬ 
ferent  platforms)  of  documents  in  respect  of  structure,  content  and  layout.  ODIF  is  an 
ASN.  1  encoding  standard  for  such  documents.  ODA/ODIF  is  a  an  ISO  standard  (ISO  8613) 
and  a  part  of  both  CALS  and  TOP.  However,  product  availability  is  still  scanty.  Although 
ODA  is  a  standard,  the  general  area  of  document  structure  and  encoding  is  still  a  studied 
topic,  and  new  findings  may  bring  about  changes  to  the  standard.  Moreover,  as  implemen¬ 
tations  appear,  some  minor  changes  to  the  standard  need  be  considered. 

B.6.8  GRAPHICAL  KERNEL  SYSTEM  (GKS) 

GKS  is  a  graphic  service  that  provides  interfaces  for  programming  two-dimensional 
graphics  in  a  device-independent  manner. 

B.6.9  PROGRAMMER’S  HIERARCHICAL  INTERACTIVE  GRAPHICS  SYS¬ 
TEM  (PHIGS) 

PHIGS,  like  GKS,  is  a  graphics  service  that  provides  interfaces  for  programming 
graphics  in  a  device-independent  manner.  While  GKS  is  two  dimensional,  PHIGS  has  a 
three-dimensional  capability.  Programming  interfaces  for  various  popular  programming 
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languages  are  available.  PEX,  the  PHIGS  Extension  to  X  Window,  has  just  become  avail¬ 
able  and  will  enhance  PHIGS’  acceptance  by  vendors  and  users. 


B.7  INFORMATION  MODELING  TOOLS  AND  METHODS 

A  wide  variety  of  information  modeling  techniques  typically  support  the  specifica¬ 
tion  and  design  phases  of  a  traditional  software  project.  The  view  here,  however,  is  broader 
than  just  software  projects.  The  information  modeling  task  could  be  that  of  modeling  the 
activities  of  an  organization  or  a  project. 

B.7.1  ICAM  DEFINITION  LANGUAGE  0  (IDEFO) 

IDEFO  is  almost  entirely  based  upon  the  Structured  Analysis  and  Design  Technique 
(SADT)  developed  by  Douglas  Ross  in  the  1970s.  The  IDEFO  method  is  used  to  model 
decisions,  actions,  and  activities  of  an  organization  and  the  relationships  between  them.  It 
supports  the  well-known  principles  of  structured  programming  and  design,  i.e.,  modular¬ 
ization,  abstraction,  information  hiding,  and  localization. 

IDEFO  has  enjoyed  substantial  success  in  defense  programs  and  projects.  A  number 
of  vendors  offer  products  that  support  IDEFO/S  ADT  modeling.  The  Air  Force  has  invested 
heavily  in  building  the  infrastructure,  developing  expertise,  and  popularizing  the  method¬ 
ology. 

B.7.2  ICAM  DEFINITION  LANGUAGE  IX  (IDEFIX) 

IDEFlx  was  developed  under  the  ICAM  program  by  Hughes  Aircraft  and 
DACOM.  It  is  a  data  modeling  technique  used  to  produce  an  information  model  that  rep¬ 
resents  the  structure  and  semantics  of  information  within  a  business  environment  or  system. 
It  makes  use  of  the  Entity-Relationship  (E-R)  approach  to  semantic  data  modeling. 

IDEFlx  is  well  tested  and  proven  in  a  number  of  Air  Force  and  private  projects. 
Therefore,  like  IDEFO,  it  is  well  understood  and  accepted.  Software  products  that  support 
IDEFlx  are  available. 

B.7.3  YOURDON 

This  methodology  was  developed  in  the  1970s  for  requirements  specification  and 
design  of  commercial  data  processing  systems,  which  are  largely  data  driven.  This  method 
models  data  flow  and  the  transformations  data  undergoes  as  it  is  processed. 

The  advantage  of  this  method  is  that  it  is  mature  and  well  understood.  It  can  be 
quickly  used  to  understand  and  graphically  document  a  data-processing  system.  This  doc¬ 
umentation  is  then  useful  for  the  next  phase,  design  and  implementation.  A  number  of 
Computer-Aided  Software  Engineering  (CASE)  vendors  offer  variants  of  this  method. 


B.7.4  JACKSON  SYSTEM  DESIGN  (JSD) 


This  method  was  developed  in  the  mid-1970s  by  Michael  Jackson  in  the  U.K.  The 
modeling  paradigm  followed  by  JSD  is  based  on  a  set  of  event-driven  processes  that  per¬ 
form  transformations  on  data.  These  processes  communicate  using  a  message-passing 
scheme,  and  read  but  do  not  modify  each  others’  data. 

Commercial  products  that  support  JSD  are  available.  It  is  also  supported  in  part  by 
many  CASE  tools.  JSD  is  popular  in  data  processing  and  transaction-oriented  applications. 
It  does  not  take  the  broad  view  of  supporting  enterprise  activity  as  a  whole. 

B.7.5  KNOWLEDGE-BASED  SYSTEMS  (KBSS) 

KBSs  have  demonstrated  their  use  as  decision-making  aids  in  complex  environ¬ 
ments.  Their  basic  approach  is  to  examine  data  about  a  system  in  light  of  domain-specific 
knowledge  that  has  been  built  into  them,  and  arrive  at  conclusions  about  the  state  of  the  sys¬ 
tem.  In  complex  business  and  manufacturing  organizations,  they  permit  large  volumes  of 
data  to  be  processed  to  arrive  at  intelligent  decisions.  KBSs  have  been  used  in  many  situa¬ 
tions. 

Specifying,  designing,  and  building  KBSs  is  a  form  of  information  modeling  task 
that  is  inherently  different  from  the  tools  and  methods  discussed  above.  Their  utility  is  in 
bringing  pre-encoded  knowledge  to  bear  on  data  in  support  of  decisions,  rather  than  passing 
data  through  a  series  of  predetermined  transformations. 

KBSs  are  often  very  narrow  in  their  area  of  applicability,  and  off-the-shelf,  applica¬ 
tion-specific  packages  are  sometimes  available.  These  can  usually  be  tuned  somewhat  to 
suit  specific  situations.  The  other  approach  to  building  such  systems  is  to  buy  commercial 
expert  system  shells  and  program  them  for  the  specific  problem  at  hand.  The  most  impor¬ 
tant  difference  between  conventional  software  development  and  building  an  expert  system 
is  that  in  the  latter,  domain  knowledge  (usually  from  an  expert)  has  to  be  codified  and  incor¬ 
porated  (the  knowledge  engineering  phase). 

KBSs  can  be  used  to  construct  a  variety  of  decision-making  aids  for  manufacturing 
enterprise  applications,  especially  in  scheduling,  optimization,  design,  and  maintenance. 
However,  the  lack  of  any  kind  of  consensus  in  standardizing  interfaces  with  other  compo¬ 
nents  of  an  information  system  (like  databases)  is  a  significant  concern. 
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B.7.6  STRUCTURED  SYSTEMS  DEVELOPMENT  (SSD) 


SSD  is  a  methodology  originated  (by  Kenneth  Orr)  in  the  mid-1970s.  It  is  based 
upon  the  use  of  Wamier  diagrams,  and  is  particularly  useful  as  an  organized  approach  to 
data  modeling.  This  method  is  often  found  integrated  with  many  CASE  tools. 

B.7.7  SEMANTIC  UNIFICATION  META-MODEL  (SUMM) 

SUMM  is  a  still  developing  technology  and  potential  standard  which  will  assist  the 
integration  of  information  models.  Work  is  currently  being  carried  out  within  the  IPO  Dic¬ 
tionary  Methodology  Committee.  Based  upon  the  use  of  first-order  predicate  logic  and  lin¬ 
guistics  principles,  SUMM  is  targeted  to  enable  the  interoperable  use  of  modeling 
languages  such  as  EXPRESS,  IDEE,  and  NIAM. 
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USER  INTERFACES 


Graphical  user  interfaces  (GUIs)  provide  a  significant  improvement  over  textual 
input  and  output.  The  technology  was  spawned  from  the  developments  in  windows  tech¬ 
nology,  graphics  hardware,  and  low-cost  computer  interfacing  devices.  The  purpose  of 
the.se  user  interfaces  is  to  provide  a  consistent,  intuitive,  and  simplified  look  to  an  applica¬ 
tion  from  the  user’s  point  of  view.  The  amount  of  code  needed  to  implement  graphical  user 
interfaces  sometimes  exceeds  the  amount  of  code  used  to  implement  the  actual  operations 
involved  in  the  application.  For  this  reason,  great  effort  has  been  devoted  to  the  develop¬ 
ment  of  graphical  user  interface  generators,  which  are  tools  that  help  accelerate  the  devel¬ 
opment  of  the  graphical  user  interface. 

B.8.1  X-WINDOWS  (X) 

X  is  a  network-oriented  windowing  system  based  on  the  client-server  model,  devel¬ 
oped  jointly  by  MIT’s  Project  Athena  and  DEC.  X  is  platform  independent.  Commonly 
associated  with  Unix  systems,  it  has  also  been  ported  to  Amiga,  Macintosh,  VMS,  and 
recently  DOS  platforms.  X  Windows  Version  11,  Release  1  (XI  1.1),  became  available  in 
September  1 987,  and  its  latest  release  of  X 1 1 .4  was  January  1 990.  Since  the  second  release, 
control  of  the  X  standard  has  been  under  the  X  Consortium  (formed  in  January  1988). 
Extensions  to  the  standard  being  considered  include  the  addition  of  the  Programmers’  Hier¬ 
archical  Interactive  Graphics  System  (PHIGS),  the  Graphical  Kernel  System  (GKS),  and 
scalable  fonts. 

B.8.2  MOTIF 

OSF  Motif  is  an  X  Window  toolkit  released  by  the  OSF  in  1987.  Motif  was  one  of 
the  candidate  toolkits  presented  to  the  IEEE  PI 201  committee  for  standardization  of  the 
toolkit  layer  of  the  X  Window  model;  it  was  rejected  (together  with  Open  Look)  because 
of  lack  of  consensus.  Motif  is  one  of  the  most  popular  X  Window  toolkits  in  commercial 
applications. 

B.8.3  OPEN  LOOK 

Open  Look  is  a  set  of  guidelines  for  developing  graphical  user  interfaces  endorsed 
by  Sun  Microsystems  and  AT&T.  The  original  development  work  was  done  by  Sun,  AT&T, 
and  Xerox  between  1986  and  1987.  Open  Look  was  one  of  the  candidates  (OSF  Motif  was 
the  other)  for  a  standard  for  the  toolkit  layer  of  the  X  Window  interface  model;  it  was  reject¬ 
ed  because  of  lack  of  consensus.  The  IEEE  PI  201  committee  abandoned  the  idea  of  stan- 


dardizing  the  toolkit  layer  of  the  X  Window  model  after  the  experience  with  Motif  and 
Open  Look.  Open  Look  conforming  GUIs  are  important  because  of  the  large  installed  base 
of  systems  produced  by  Sun  Microsystems  and  AT&T. 

B.8.4  POSIX  1201  (XVT) 

Efforts  to  produce  a  standard  toolkit  for  X  have  been  hindered  by  the  fierce  compe¬ 
tition  between  Motif  and  Open  Look.  Current  standardization  efforts  concentrate  on  pro¬ 
viding  a  software  layer  on  top  of  the  toolkits  that  will  make  application  programs  toolkit 
independent.  This  layer  is  referred  to  as  a  Layered  Application  Program  Interface  (LAPI), 
and  was  submitted  for  consideration  to  the  IEEE  PI20L1  committee  by  XVT,  the  U.S.  Air 
Force  Strategic  Air  Command  (SAC),  and  the  National  Aeronautics  and  Space  Adminis¬ 
tration  (NASA).  The  P1201.1  has  recently  selected  the  XVT  proposal  as  the  basis  for  the 
standard. 


B.8.5  MS-WINDOWS 

Microsoft  Windows  3.0  is  a  GUI  intertwined  with  operating  system  functionality 
that  runs  under  MS-DOS.  Windows  3.0  includes  its  own  API.  Microsoft  and  third  parties 
provide  software  development  tools  for  MS-Windows.  Windows/NT,  under  development, 
is  an  extension  to  Windows  3.0  that  will  run  on  Unix  platforms. 

B.8.6  PRESENTATION  MANAGER 

Presentation  Manager  (PM),  developed  for  IBM  by  Microsoft,  is  the  GUI  provided 
with  the  IBM  OS/2  operating  system.  Presentation  Manager  conforms  to  IBM’s  SAA 
guidelines. 

B.8.7  DECWINDOWS 

DECWindows  is  a  proprietary  product  of  DEC.  It  supports  and  enhances  the  X  Win¬ 
dow  System;  current  implementations  use  the  XUI  (X  User  Interface)  toolkit.  DEC  plans 
to  migrate  to  OSF/Motif.  Extensions  of  X  included  in  DECwindows  are  Imaging  Postscript 
and  PEX  (PHIGS  -i-  Extension  to  X). 

B.8.8  MACINTOSH  TOOLBOX 

The  Macintosh  Toolbox  was  the  first  widely  accepted  GUI.  The  Toolbox  is  a  library 
of  routines  implemented  in  ROM  and  is  the  only  user  interface  provided  to  Mac  applica¬ 
tions.  This  fact,  and  Apple’s  public  guidelines  for  interface  programming,  has  led  to  con¬ 
sistency  in  its  use. 


B.9 


PROGRAMMING  LANGUAGES 


The  languages  reviewed  are  a  sample  of  the  most  commonly  used  and  popular  lan¬ 
guages.  The  languages  were  developed  to  satisfy  different  needs  in  different  areas  of  com¬ 
puter  programming.  Even  when  they  are  based  on  completely  different  programming 
paradigms,  they  can  still  be  classified  as  general  purpose  programming  languages. 

B.9.1  ADA 

Ada  is  a  general  purpose  programming  language  developed  by  the  French  company 
Cii-Honeywell  Bull  under  contract  from  the  U.S.  Department  of  Defense  (DoD)  after  a 
competitive  selection  process.  It  is  the  only  language  among  the  ones  described  here  that 
was  developed  following  the  criteria  of  this  process.  The  Ada  Language  Reference  Manual 
was  published  in  1980,  and  the  language  became  a  national  standard  in  1983  (ANSI/MIL- 
STD-1815-A)  and  an  international  standard  in  1987  (ISO  8652).  The  language  was  devel¬ 
oped  using  Pascal  and  Algol-68  as  a  baseline.  Ada  provides  more  features  and  directly 
implements  more  concepts  useful  for  effective  software  engineering  than  any  of  the  other 
languages  described  in  this  section.  The  language  was  created  to  control  the  high  costs  of 
maintenance  brought  about  by  the  proliferation  of  multiple  languages  and  dialects  in  the 
different  branches  of  the  DoD  for  embedded  software  applications.  The  language  is  still  a 
general  purpose  language  used  in  applications  other  than  embedded  systems,  and  the  DoD 
has  directed  that  Ada  be  used  in  DoD  systems  development. 

B.9.2  C 

C  is  a  general  purpose,  high-level  programming  language  used  in  various  kinds  of 
software  development,  including  operating  systems,  system  level  software  (e.g.,  special 
purpose  processors),  and  business  and  scientific  application  software.  It  was  developed  at 
the  AT&T  Bell  Laboratories  by  Dennis  Ritchie  during  the  1970s  and  has  become  popular 
because  of  its  close  association  with  the  development  of  the  Unix  operating  system. 

The  national  standard  for  C  (ANSI  X3J1 1)  was  approved  in  December  1989  after  a 
long  process.  The  international  standard  (ISO/IEC  9899)  is  still  in  the  draft  stage. 

B.9.3  C++ 

C+-I-  is  one  of  the  object-oriented  extensions  to  the  C  language.  C-i-i-  was  developed 
at  AT&T  by  Bjarne  Stroustroup  in  the  late  1 980s.  Except  for  a  few  details,  C+-r  is  a  superset 
of  C.  C-i-t-  incorporates  the  concept  of  classes  by  extending  the  C  structure  construct.  It  also 
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provides  better  type  checking  and  other  facilities  not  available  in  C.  The  latest  version  of 
C++  (Version  2.0)  incorporates  multiple  class  inheritance. 

B.9.4  COBOL 

Cobol  is  a  language  widely  used  since  the  early  1960s  for  business  applications  of 
computers.  As  is  the  case  with  most  other  widely  used  languages,  Cobol  has  evolved 
through  a  sequence  of  design  revisions,  beginning  with  the  first  version  in  1960,  the  second 
in  1972,  and  the  latest  standard  in  1985  (ANSI  X3.23-1985,  ISO  1989-1985),  revised  again 
in  1989  (addendum  X3.23A). 

Cobol  is  designed  for  use  in  programming  self-documenting,  business-oriented 
applications.  An  estimated  60  to  80%  of  Federal  government  applications  are  written  in 
Cobol.  Major  vendors  offer  Federal  Information  Processing  Standards  (FIPS)  Cobol. 

The  current  standard  does  not  include  real-time  operating  system  and  communica¬ 
tions  components.  It  is  most  complete  in  the  areas  of  data  manipulation  and  business-finan¬ 
cial  applications.  The  X3J4  committee  is  in  the  process  of  adding  new  functionality  for 
communication  interfaces  and  screen  management,  and  compatibility  with  previous  ver¬ 
sions  of  the  standard  will  be  maintained.  Historically,  such  compatibility  has  been  one  of 
Cobol’s  stronger  points. 

B.9.5  FORTRAN 

Fortran  is  a  widely  used  language  for  scientific  and  numeric  computing.  The  design 
of  the  language  centers  around  a  single  primary  goal;  execution  efficiency.  Fortran  was 
developed  in  the  1950s  before  structured  programming  concepts  were  developed.  Succes¬ 
sive  revisions  (Fortran  66,  Fortran  77  (ANSI  X3.9-1978,  ISO  1539-1980),  Fortran  90)  have 
incorporated  structured  programming  elements  to  the  language.  For  example,  the  “if-then- 
else”  control  structure  was  added  in  the  Fortran  77  standard,  and  “do-while”  and  case  state¬ 
ments  were  incorporated  in  the  Fortran  90  standard.  The  latest  Fortran  standard  is  Fortran 
90  (ANSI  X3J3),  approved  in  April  1991. 

Fortran  was  originally  developed  to  assist  in  the  development  of  scientific  calcula¬ 
tion  applications,  but  it  has  since  been  extended  to  cover  other  types  of  applications.  Librar¬ 
ies  are  available  for  assisting  in  the  development  of  information  systems,  real-time,  and 
process  control  systems.  An  IEEE  Working  Group  is  currently  defining  a  POSIX/Fortran 
binding. 


B.9.6  LISP 


Lisp  was  designed  by  John  McCarthy  and  implemented  in  the  late  1 950s  at  MIT. 
Lisp  was  designed  to  manipulate  symbolic  rather  than  numeric  data  and  is  a  very  popular 
language  within  the  artificial  intelligence  community.  Over  the  past  30  years  several  Lisp 
dialects  have  been  developed,  with  the  ANSI  X3J 13  subcommittee  currently  standardizing 
a  dialect  known  as  Common  Lisp.  Drafts  of  the  standard  have  gone  through  many  reviews, 
and  the  committee  is  now  in  the  process  of  writing  the  standard  in  specification  form. 

Lisp  is  a  very  flexible  programming  language,  with  a  simple  and  uniform  syntax.  It 
is  interactive  and  is  usually  embedded  in  a  programming  environment  that  includes  dynam¬ 
ic  storage  allocation  and  automatic  garbage  collection,  incremental  compilation,  and  lan¬ 
guage  extensibility. 

Flavors  (MIT)  and  Loops  (Xerox  PARC)  are  two  object-oriented  extensions  to  Lisp. 
The  Common  Lisp  Object  System  (CLOS)  is  an  object-oriented  extension  to  Common 
Lisp. 

B.9.7  PASCAL 

Pascal  was  created  by  Nicklaus  Wirth  in  the  early  1970s  to  provide  a  language  suit¬ 
able  for  teaching  computer  programming  as  a  systematic  discipline.  The  language  is  based 
on  fundamental  computer  programming  concepts. 

Pascal  is  a  structured  programming  language  still  primarily  used  in  teaching  envi¬ 
ronments  for  training  computer  science  students  in  the  concepts  of  programming.  It  has 
also  gained  popularity  in  general  application  areas  such  as  business,  science,  engineering, 
and  U.S.  Government  applications.  National  and  international  standards  for  the  language 
were  approved  in  1983  (ANSI/IEEE  770X3.97,  ISO  7185). 

B.9.8  PROLOG 

Prolog  is  an  implementation  of  predicate  logic  as  a  programming  language.  The  ori¬ 
gins  of  the  language  are  in  mathematical  theorem  proving,  developed  in  the  early  1 970s  at 
the  Faculty  of  Sciences  at  Luminy  in  Marseilles,  France.  Interest  in  the  language  received 
a  boost  from  the  Japanese  fifth  generation  computer  effort,  formally  started  in  1981,  which 
selected  Prolog  as  the  language  of  choice  for  knowledge  processing  and  artificial  intelli¬ 
gence  applications. 

Prolog  is  a  non-procedural  language.  In  procedural  languages  one  specifies  step  by 
step  how  computations  are  carried  out  by  the  computer.  In  Prolog  one  specifies  facts  and 
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rules  about  relationships  among  entities  and  then  asks  questions  about  the  relationships. 
Prolog  extensively  uses  recursion  and  a  unique  backtracking  mechanism,  and  its  variables 
do  not  represent  storage  locations.  A  Prolog  procedure  is  a  collection  of  rules  rather  than  a 
single  closed  module  of  a  subroutine. 

Prolog  is  a  popular  language  used  in  artificial  intelligence  applications,  such  as 
expert  systems  and  knowledge  engineering.  Other  applications  include  symbolic  computa¬ 
tion,  natural  language  processing,  very  high-level  languages,  natural  language  interfaces  to 
databases,  deductive  databases,  and  automatic  programming. 

Implementations  of  Prolog  have  been  available  since  the  mid-1980s.  Prolog  exists 
in  multiple  dialects,  with  implementations  from  Marseilles  and  the  University  of  Edin¬ 
burgh,  Scotland,  being  the  most  widely  used. 

B.9.9  SMALLTALK 

Smalltalk  was  developed  by  the  Learning  Research  Group  at  Xerox  PARC  during 
the  1970s.  The  first  commercial  version  of  Smalltalk-80  was  released  in  1983,  with  the  first 
versions  running  on  personal  computers.  One  example  is  Smalltalk  V,  which  became  avail¬ 
able  in  1986. 

Smalltalk  is  a  programming  system  instead  of  an  isolated  language.  It  provides  an 
interactive  development  environment  that  includes  a  user  interface  graphics  toolkit,  which 
makes  it  particularly  useful  for  exploratory  programming  and  rapid  prototyping.  A  salient 
characteristic  of  the  Smalltalk  environment  is  that  the  programmer  has  access  to  every  part 
of  the  system,  including  its  implementation.  The  syntax  of  Smalltalk  is  simple  and  concep¬ 
tually  powerful,  as  it  uses  two  basic  concepts,  objects  and  messages. 

The  Smalltalk  language  demonstrated  that  object-oriented  programming  is  a  very 
useful  technique  for  software  development,  and  has  had  a  major  influence  in  the  develop¬ 
ment  of  other  object-oriented  languages. 
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B.IO  SECURITY  TOOLS  AND  METHODS 

In  a  distributed  computing  environment  in  which  large  volumes  of  data  are  being 
constantly  accessed,  used,  and  updated,  security  plays  a  major  role.  Some  data  is  restricted 
to  certain  individuals,  while  other  data  is  meant  for  machines.  This  section  deals  with  con¬ 
trolling  individuals’  access  to  data  and  computing  services  in  a  networked  environment. 

B.10.1  POSIX  1003.6 

This  POSIX  committee,  formed  in  March  1988,  has  been  charged  to  “develop  spec¬ 
ifications  for  standard  interfaces  to  security  services  and  mechanisms  for  portable  applica¬ 
tions.”  These  specifications  will  include  system  call  interfaces  and  system  commands. 
POSIX  1003.6  focuses  mainly  on  access  control  and  audit  logging  services. 

This  standard  is  still  in  draft  form  and  in  the  process  of  balloting.  It  is  expected  to 
be  a  full  IEEE  standard  by  mid- 1992.  Thus  there  are  no  current  products  that  conform  to 
this  standard.  However,  a  number  of  Unix  variants  offer  access  control  list  services. 
Because  this  standard  will  be  part  of  the  POSIX  family,  it  is  of  strategic  importance  to 
builders  and  users  of  open  computing  platforms. 

B.10.2  KERBEROS 

Kerberos  is  a  trusted  third-party  authentication  service  that  was  developed  as  part 
of  Project  Athena  at  M.I.T.  It  uses  an  authentication  server,  which  is  the  only  entity  on  the 
network  that  knows  the  passwords.  Both  users  and  services  have  passwords,  thereby  per¬ 
mitting  users  access  to  only  the  desired  set  of  services. 

Kerberos  has  been  adopted  by  OSF  for  its  Distributed  Computing  Environment 
(OSF/DCE).  It  has  been  widely  used  in  a  large  university  environment  with  considerable 
success. 

B.10.3  DATA  ENCRYPTION  STANDARD  (DES) 

DES,  an  encryption  standard  that  originated  at  IBM,  was  adopted  by  the  U.S.  Gov¬ 
ernment  in  1977.  DES  is  now  a  part  of  GOSIP,  version  2.  It  is  a  complex  product  cipher 
with  an  algorithm  that  is  freely  available  on  hardware,  and  is  therefore  popular  in  applica¬ 
tions  such  as  banking  transactions  that  demand  security,  but  not  at  the  extreme  level  of  mil¬ 
itary  operations. 
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APPENDIX  C.  ORGANIZATION  AND 
PROGRAM  DEPLOYMENT  FORCES  MATRICES 


Table  C-1.  Integration  Frameworks  and  Architectures 


TECHNICAL  DEVELOPMENT 

MARKET  BUILDING 

MODELING 

STANDARDS 

METHOD/TOOL 

PROTOTYPE 

STANDARD 
VALIDATION  /DEMO 

PRODUCT 

CERTIFICATION 

USER 

GUIDELINES 

AWARENESS  & 
EDUCATION 

SAA 

•  IBM“ 

•  IBM 

•  IBM 

•  IBM 

•  IBM 

•  IBM 

•  IBM 

•  Private 

NAS 

•  DEC 

•  DEC 

•  DEC 

•  DEC 

•  DEC 

•  DEC 

•  DEC 

•  Private 

PCTE 

•  ECMA 

•  TC33 

•  ECMA 

•  TC33 

•  Private 

•  Private 

•  Private 

•  Private 
Users 
Group 

HP 

New  Wave 

•  HP 

•  HP 

•  HP 

•  HP 

•  HP 

•  HP 

•  HP 

•  Private 

a.  Different  parts  of  IBM  responsible  for  technical  development  stages. 


Table  C-2.  Operating  Systems  and  Distributed  Environments 


TECHNICAL  DEVELOPMENT 

MARKET  BUILDING 

MODELING 

STANDARDS 

METHOD/TOOL 

PROTOTYPE 

STANDARD 

VALIDATION/DEMO 

PRODUCT 

CERTIFICATION 

USER 

GUIDELINES 

AWARENESS  & 
EDUCATION 

POSIX 

•  IEEE 

•  IEEE 

•  ISO/IEC 

•  IEEE 

•  Private 

•  IEEE 

•  NIST 

•  X/OPEN 

•  X/OPEN 

•  IEEE 

•  X/OPEN 

UNIX 

SVR4 

•  AT&T 

•  UI 

•  UI 

•  UI 

•  UI 

•  AT&T 

•  (code) 

•  UI 

•  UI 

OSF/1. 

OSF/DCE 

*  OSF 

•  OSF 

•  OSF 

•  OSF 

•  OSF 

•  OSF 

•  OSF 

•  OSF 

• 

OMG 

•  University 

•  Private 

•  OMG 

•  OMG 

•  University 

•  Private 

•  University 

•  Private 

• 

•  OMG 

•  University 

•  Private 

MS-DOS 

•  Microsoft 

•  Microsoft 

•  (de  facto) 

•  Microsoft 

•  Microsoft 

•  Private 

•  Microsoft 

•  Microsoft 

•  Microsoft 

•  Others 

Table  C-3.  Communications 


TECHNICAL  DEVELOPMENT 

MARKET  BUILDING 

MODELING 

STANDARDS 

METHOD/TOOL 

PROTOTYPE 

STANDARD 

VALIDATION/DEMO 

PRODUCT 

CERTIFICATION 

USER 

GUIDELINES 

AWARENESS 
&  EDUCATION 

OSI 

•  ISO 

• 

IEEE 

•  NIST 

•  NIST 

•  MAPyTOP 

•  COS 

•  COS 

•  COS 

MAP/ 

• 

ccnr 

•  CNMA 

•  Private 

•  NIST 

•  NIST 

•  NIST 

•  INTEROP 

TOP 

• 

ANSI 

•  Private 

•  Public 

•  CNMA 

•  CCT 

•  SME 

•  SME 

GOSIP 

• 

NIST- 

•  Domain 

•  SPAG 

•  NCC 

•  Private 

OIW 

• 

ECMA 

EWOS 

TCP/IP 

•  DARPA 

• 

DARPA 

•  BBN 

•  BBN 

•  DARPA 

•  AD  HOC 

•  DARPA 

•  lAB 

•  lAB 

• 

lAB 

•  University 

•  DARPA 

*  University 

•  NSF 

•  INTEROP 

•  University 

•  Trade 

Demos 

•  Private 

Table  C-4.  Data  Management  Systems 


TECHNICAL  DEVELOPMENT 

MARKET  BUILDING 

MODELING 

STANDARDS 

METHOD/TOOL 

PROTOTYPE 

STANDARD 

VALIDATION/DEMO 

PRODUCT 

CERTIFICATION 

USER 

GUIDELINES 

awar:eness  & 

EDUCATION 

IRDSl 

•  NIST/ 

•  ANSI/ 

•  SPARC 

•  ANSI 

*  ANSI 

RDA 

Protocol 

•  OSI 

•  ISO/IEC 

•  SAG 

•  SAG 

•  X/OPEN 

•  SAG 

•  X/OPEN 

SQL 

•  RDBMS 

*  ANSI 

•  SAG 

*  Private 

•  SAG 

•  SAG 

•  SAG 

IRDS2 

•  OODBMS 

•  Model 

•  ANSI 

•  ISO 
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Table  C-5.  Application  Development  Tools  and  Methods 


TECHNICAL  DEVELOPMENT 

MARKET  BUILDING 

MODELING 

STANDARDS 

METHODATOOL 

PROTOTYPE 

STANDARD 

VALIDATION/DEMO 

PRODUCT 

CERTIFICATION 

USER 

GUIDELINES 

AWARENESS  & 
EDUCATION 

X/OPEN 

•  ISO 

•  X/OPEN 

•  Private 

•  Private 

•  X/OPEN 

and 

•  MAPA’OP 

•  Private 

POSIX 

•  IEEE 

APIs 

•  Private 

Table  C-6.  Data  Representation 


TECHNICAL  DEVELOPMENT 

MARKET  BUILDING 

MODELING 

STANDARDS 

METHOD/TOOL 

PROTOTYPE 

STANDARD 

VALIDATION/DEMO 

PRODUCT 

CERTIFICATION 

USER 

GUIDELINES 

AWARENESS  & 
EDUCATION 

IGES 

•  IPO 

•  PDES,  Inc. 

•  PDES,  Inc. 

•  IPO 

•  CAD  DETC 

•  IPO 

•  IPO 

PDES/ 

•  IPO 

•  Private 

•  (starting) 

•  Users 

STEP 

■■ 

•  Private 

Groups 

•  Private 

•  ISO 

•  ISO 

•  NIST 

*  NIST 

•  NIST 

ODIF/ 

•  ANSI 

•  ANSI 

•  ANSI 

•  NIST 

•  CALS 

•  CALS 

SGML 

•  ISO 

•  ISO 

•  CALS 

•  NIST 

EDI 

•  ANSI 

•  Private 

•  Private 

•  AlAG 

•  AIAG 

•  CALS 

•  ANSI 

•  AIAG 

•  CALS 

Table  C-7.  Information  Modeling  Tools  and  Methods 


Table  C-8.  User  Interface 


TECHNICAL  DEVELOPMENT 


MARKET  BUILDING 


Macintosh 

Toolbox 


DEC- 

Windows 


Presentation 

Manager 


METHOD/TOOL 

PROTOTYPE 

STANDARD 

VALIDATION/DEMO 

•  MIT-X 
Consortium 

•  MIT-X 
Consortium 

•  MIT-X 
Consortium 

•  OSF 

•  Private 

*  OSF 

•  OSF 

•  Private 

•  UI 

•  Private 

•  Ul 

•  UI 

•  Private 

•  Microsoft 

•  Private 

•  Microsoft 

•  Microsoft 

♦  Private 

•  Apple 

•  Apple 

•  Apple 

•  DEC 

•  DEC 

•  DEC 

•  IBM 

•  Private 

•  IBM 

•  IBM 

IBM 

Private 
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Table  C-9.  Programming  Languages 


TECHNICAL  DEVELOPMENT 

MARKET  BUILDING 

MODELING 

STANDARDS 

METHOD/TOOL 

PROTOTYPE 

STANDARD 

VALIDATION/DEMO 

PRODUCT 

CERTIFICATION 

USER 

GUIDELINES 

AWARENESS  & 
EDUCATION 

c 

Fortran 

Pascal 

Cobol 

•  ANSI 

•  IEEE 

(POSIX) 

•  Private 

•  Private 

•  Private 

Ada 

♦  DoD 

•  IEEE 

•  ANSI 

•  SEI 

•  Private 

•  SEI 

•  SEI 

•  DoD 

•  AJPO 

•  SEI 

♦  DoD 

C++ 

•  AT&T 

•  Private 

•  Pnvate 

•  Private 

Table  C-10.  Security  Tools  and  Methods 


TECHNICAL  DEVELOPMENT 

MARKET  BUILDING 

MODELING 

STANDARDS 

METHOD/TOOL 

PROTOTYPE 

STANDARD 

VALIDATION/DEMO 

PRODUCT 

CERTIFICATION 

USER 

GUIDELINES 

AWARENESS  & 
EDUCATION 

Kerberos 

•  MIT 

•  MIT 

•  MIT 

•  MIT 

•  MIT 

•  MIT 

•  OSF 

•  OSF 

•  OSF 

*  OSF 

•  OSF 

DES 

•  ISO 

•  NIST 

•  NIST 

•  NIST 

•  NIST 

•  NIST 

•  NIST 

(GOSIP) 

POSIX 

•  POSIX 

•  POSIX  (in 

•  OSF 

1003.6 

program) 

APPENDIX  D.  DESCRIPTIONS  OF 
EIP  NEEDS  AND  REQUIREMENTS 
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NEEDS 


# 


The  needs  in  the  EIP  Business  Needs  and  Requirements  Matrix,  Figure  2  on  page 
20,  are  defined  in  the  following  subsections. 

Customer  Oriented 

Reduce  Costs 

Reduce  information  system  cost:  Costs  of  information  systems  include  the  pur¬ 
chase  of  hardware  and  software,  development,  and  system  support  and  mainte¬ 
nance. 

Reduce  costs  of  new  product  introduction:  Costs  associated  with  new  product 
introduction,  from  conception  through  the  establishment  of  manufacturing 
operations. 

Reduce  costs  of  post-product  distribution  and  field  support:  The  cost  of  manag¬ 
ing  a  product  after  it  leaves  the  factory.  Included  are  costs  of  distribution,  sup¬ 
port,  warranty,  archiving  product  and  customer  information,  disposing  of 
obsolete  material  and  equipment,  and  providing  spares  and  service. 

Reduce  material  cost:  Cost  of  material  used  in  production. 

Reduced  overhead  cost:  Overhead  costs  include  all  costs  that  do  not  contribute 
directly  to  “making  the  product.”  Examples  include  white  collar  salaries, 
energy,  and  administrative  and  marketing  expenses. 

Reduce  labor  cost:  Labor  costs  are  those  applied  directly  to  product  manufac¬ 
turing,  e.g.,  “touch”  labor. 

Improved  Product  Quality 

Performance:  The  primary  operating  characteristics  of  a  product. 

Features:  Those  secondary  characteristics  that  supplement  the  product's  basic 
functioning.  An  example  would  be  air  conditioning  in  a  car. 

Reliability! Durability:  Reliability  reflects  the  probability  of  a  product's  mal¬ 
functioning  or  failing  within  a  specific  period  of  time.  Durability  is  a  measure 
of  product  life  in  both  economic  and  technical  dimensions. 

Conformance:  The  degree  to  which  the  product  meets  its  design  specification. 

Serviceability:  The  measure  of  how  quickly  and  easily  a  product  can  be  repaired 
upon  failure,  and  how  easily  maintenance  can  be  performed. 
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Aesthetics:  How  a  product  looks,  feels,  tastes,  sounds,  or  smells.  It  is  a  matter 
of  personal  judgment. 

Perceived  quality:  A  subjective  measure  based  on  an  individual's  prior  biases 
and  prejudices.  Reputation  is  a  primary  contributor  to  perceived  quality. 

Deliver  Products  in  a  Timely  Manner 

Reduce  Engineering  Change  Notices  (ECNs):  Reducing  the  number  of  changes 
made  to  a  design  after  it  has  been  formally  communicated  downstream. 

Fast  engineering  process:  Efficiency  of  the  design  process,  no  wasted  steps  of 
processes. 

Reduce  number  of  prototypes:  Making  each  prototype  conform  as  closely  as 
possible  to  the  final  product  to  minimize  the  time  and  expense  of  making  addi¬ 
tional  prototypes. 

Improve  integration  of  lines:  Design  manufacturing  processes  so  that  the  output 
of  one  machine  can  go  directly  into  another  machine  without  human  interven¬ 
tion. 

Reduce  number  of  process  changes:  Reduce  the  number  of  changes  made  in  the 
product  manufacturing  process  after  it  has  been  designed. 

Faster  tooling  delivery:  Fast  design  and  manufacture  of  tools  so  that  the  tools 
can  be  delivered  sooner.  This  aids  in  rapid  debugging  of  manufacturing  pro¬ 
cesses. 

Reduce  cost  of  tooling:  Reduce  labor  and  material  spent  on  design  and  produc¬ 
tion  of  tooling. 

Predictable  suppliers:  Suppliers  who  can  respond  in  a  predictable  manner  to 
changes  in  product  demand. 

Improve  supplier  planning  capacity:  Assist  suppliers  in  planning  their  schedul¬ 
ing,  routing,  and  capacity  planning  to  promote  better  integration  within  the 
enterprise. 

Stable  build  schedules:  Stable  production  schedules  allow  reliable  fabrication 
and  assembly  schedules  to  be  generated  and  make  it  easier  for  suppliers  to  pro¬ 
vide  on-time  delivery. 

Supplier  quality:  Improve  quality  of  supplier  parts  to  support  stable  schedules 
and  just-in-time  (JIT)  inventory  practices. 


# 


# 
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Running  the  Business 

Market  Development 

Market  development:  A  vendor's  ability  to  identify,  reach,  and  generate  demand 
within  potential  markets. 

Access  Information 

Payables  and  receivables:  Rendering  payment  to  debtors,  collecting  payment 
for  goods  and  services. 

Personnel:  Personnel  information  includes  all  data  on  a  company's  employees, 
including  prior  work  activity,  training,  skills  inventory,  pay,  taxes,  and  benefits. 
Cost  allocation:  Information  and  logic  applied  to  determining  the  proper  allo¬ 
cation  of  funds  to  produce  a  product.  Included  are  all  sources  of  expense — cap¬ 
ital,  department,  office  operations,  strategic  planning,  etc. 

Product  pricing:  Determination  of  the  sale  price  of  a  product.  Derived  from 
market  considerations  and  from  analysis  of  costs  of  manufacturing,  overhead, 
labor,  and  materials. 

Justify  Investments 

Small  firms  need  skills  to  make  case  for  enterprise  integration  (El)  investment: 
Small  firms  do  not  have  the  expertise  to  develop  a  persuasive  case  to  banks  and 
other  capital  sources  for  investment  in  EL 

Small  firms  lack  information  to  make  case  for  El  investment:  Small  firms  have 
difficulty  obtaining  information  to  support  a  case  for  investment  in  El. 

Big  firms  lack  accounting  processes  to  support  El:  Traditional  accounting  pro¬ 
cesses  do  not  provide  the  data  necessary  to  track  cost  in  a  manner  that  is  condu¬ 
cive  to  justifying  capital  investments  in  El. 

Legal,  Security,  Regulation 

Reduce  risk  of  legal  claims:  Risk  comes  from  two  sources:  (1)  liability  associ¬ 
ated  with  activity  at  different  points  in  a  product's  life  cycle,  and  (2)  lack  of 
compliance  with  regulatory  requirements. 
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Security:  Security  systems  to  protect  information  from  unauthorized  access. 
Included  are  topics  such  as  product  designs,  process  operations,  personnel, 
finance,  accounting,  and  strategic  planning. 

Environmental  regulation:  Information  needed  throughout  a  product’s  life  cycle 
to  demonstrate  compliance  with  Environmental  Protection  Agency  (EPA)  reg¬ 
ulations. 

OSH  A  regulation:  Information  needed  throughout  a  product’s  life  cycle  to  dem¬ 
onstrate  compliance  with  regulations  of  the  Occupational  Safety  and  Health 
Administration  (OSHA). 

Financial  regulation:  Information  needed  throughout  a  product’s  life  cycle  to 
demonstrate  compliance  with  financial  regulations.  Included  are  data  on  earn¬ 
ings,  sales,  purchasing,  stocks,  retirement  funds,  payroll,  and  any  other  financial 
activity  that  may  be  monitored  for  compliance. 

EEO  regulation:  Information  needed  to  demonstrate  compliance  with  the  regu¬ 
lations  of  the  Equal  Employment  Opportunity  (EEO)  Commission. 


D.2  REQUIREMENTS 

The  requirements  in  the  EIP  Business  Needs  and  Requirements  Matrix,  Figure  2  on 
page  20,  and  the  .EIP  Requirements  and  Technologies  Matrix,  Figure  3  on  page  22,  are 
defined  as  follows. 

Generic  Requirements 

Information  Systems  Integration 

Communication  standards:  Protocols  that  describe  how  the  exchange  of  infor¬ 
mation  will  occur  between  sub-units  of  an  enterprise. 

SystemI network  administration  standards:  Standards  for  backup  and  restore 
activities. 

Data  interchange  standards:  Established  protocols  or  rules  of  data  representa¬ 
tion,  compatibility,  and  commonality  to  facilitate  the  sharing  of  common  data 
between  enterprises.  The  Product  Data  Exchange  Standard  (PDES)  and  STan- 
dard  for  the  Exchange  of  Product  Data  (STEP)  are  examples. 

Reuse  of  knowledge  modules:  The  reuse  or  dual  use  of  tools,  software,  product 
data,  and  group  technology  for  multiple  business  needs. 

Long-term  maintenance  and  access  of  data:  Established  protocol  for  the  main¬ 
tenance,  storage,  and  retrieval  of  data  over  an  entire  product  life  cycle. 

Handle  large  quantity  of  data:  The  ability  to  administer,  access,  maintain,  and 
transmit  large  volumes  of  data. 

Modular  applications,  systems:  Applications  that  have  well-defined  boundaries 
and  interfaces  that  allow  use  in  a  variety  of  different  contexts. 

Application  platform  independence  and  interoperability:  The  isolation  of  appli¬ 
cations  from  specific  operating  systems  or  hardware  platforms. 

Distributed  applications,  systems:  Applications  and  systems  in  multiple  loca¬ 
tions,  working  in  cooperation.  The  actual  location  of  any  part  of  the  application 
or  system  is  irrelevant  to  the  user. 

Data  management:  The  activity  of  controlling  the  acquisition,  analysis,  storage, 
retrieval,  and  distribution  of  data. 

Design  tools:  Tools  that  can  be  used  to  support  El  as  it  relates  to  the  design  of 
products  and  process. 


D-7 


Migration  management:  For  users,  the  migration  of  existing  data  and  systems 
to  an  integrated  environment.  For  vendors,  the  ability  to  control  life  cycle 
changes  in  a  product  line. 

Enterprise  framework  and  architecture:  An  orderly,  comprehensive  structure 
that  can  be  used  to  specify,  evaluate,  implement,  and  maintain  an  enterprise’s 
infonnation,  business  processes,  and  operational  needs. 

Tools! procedures  for  El  development  and  testing:  Tools  and  methods  that  will 
help  implement  integrated  systems  and  applications,  describe  the  current  model 
of  the  enterprise,  and  verify  and  test  any  changes. 

Human  Factors 

Consistent  user  interface:  A  consistent  means  of  presenting  information  across 
systems  and  applications.  Used  to  reduce  the  amount  of  learning  required  to 
interact  with  a  system. 

Psychologically  compatible  interface:  Interfaces  that  present  information  in  a 
form  that  is  compatible  with  people’s  familiar  methods  of  perception  and  infor¬ 
mation  processing. 

Quality 

Bounded  customization:  A  characteristic  of  a  product  that  allows  users  to  cus¬ 
tomize  it  for  their  particular  needs  without  presenting  the  vendor  with  an  uncon¬ 
trollable  (and  unknowable)  variety  of  unique  installations. 

Establish  process  based  on  customer  requirements:  Processes  established  to 
support  the  development  of  products  and  services  that  meet  the  needs  of  internal 
and  external  customers. 

Process  control  and  feedback:  A  means  of  measuring  the  performance  of  a  pro¬ 
cess,  comparing  performance  to  specification,  and  guiding  necessary  corrective 
action. 

Simplified  processes:  Processes  designed  so  as  to  remove  complexity  and  min¬ 
imize  waste  of  resources.  Optimization  should  be  considered  from  the  highest 
or  most  global  viewpoint. 

Buildable  products.  Products  that  can  be  implemented  by  vendors. 

Continuous  improvement  (Cl):  A  commitment  to  proactive,  continual  participa¬ 
tion  by  employees  in  the  analysis  and  improvement  of  the  processes  of  which 


they  are  a  part.  Each  employee,  through  continuous  participation  in  Cl.  assumes 
joint  ownership  and  management  of  those  processes  through  which  products 
and  services  are  delivered  right  the  first  time. 

Management  by  fact:  An  emphasis  on  decisions  based  on  reliable  data  and  anal¬ 
ysis.  Also,  a  concerted  effort  to  develop  performance  indicators  to  assess  prod¬ 
uct  characteristics,  process  characteristics,  and  company  operations. 

Organization 

Linkage 

Cross-disciplinary,  entrepreneurial  teams:  Teams  that  cross  disciplinary  and/or 
functional  boundaries  and  have  a  charter  to  “start  something  new.”  These  may 
be  ad  hoc  or  permanent,  within  or  between  an  organizations  (e.g.,  between 
prime  and  subcontractors),  and  include  employees  at  the  same  or  multiple  lev¬ 
els. 

Balance  centralization  and  decentralization:  Decision  making  needs  to  made  at 
the  lowest  appropriate  level.  Over-centralization  yields  decision  makers  who 
lack  information  and  the  ability  to  directly  influence  events.  Over-decentraliza¬ 
tion  yields  decision  makers  who  lack  perspective  and  large-scale  influence. 

Design  in  the  large:  The  ability  to  coordinate  large,  complex  design  projects 
involving  many  parts  and  components,  multiple  design  teams,  and  multiple  sup¬ 
plier  levels. 

Production  scheduling  and  JIT  in  the  large:  The  ability  to  coordinate  the  pro¬ 
duction  of  large,  complex  products  involving  many  parts  and  components  and 
multiple  suppliers  using  JIT  methods. 

Concurrent  engineering:  Coordinating  multiple  phases  of  the  engineering  life 
cycle  (e.g.,  product  design,  process  design)  so  that  their  activities  overlap. 

Job  Design  and  Rewards 

Clear  expectations  of  performance:  A  clear  understanding  on  the  part  of  indi¬ 
viduals  of  what  they  are  expected  to  do,  what  they  will  be  rewarded  for,  how 
they  will  be  rewarded  if  they  meet  these  expectations,  and  how  their  behavior 
relates  to  larger  organizational  objectives. 


Expand  job  to  include  problem  solving  and  decision  making:  Job  designs 
(including  those  of  workers  on  the  shop  floor)  that  explicitly  include  some 
degree  of  problem  solving  and  decision  making. 

Job  satisfaction  and  worker  motivation:  Jobs  designed  to  enhance  the  motiva¬ 
tion  and  satisfaction  of  individuals  who  hold  them,  thus  leading  to  proactive 
problem  solving  and  less  employee  turnover. 

Skills 

Job  specific  skills:  Skills  specific  to  an  individual  job,  including  basic  education 
levels  required  to  perform  the  job. 

Change  Management 

Strategic  plan:  A  formal  long-range  plan. 

Management  and  labor  relations:  Quality  of  the  working  relationship  between 
those  in  management  positions  and  those  who  are  not.  In  a  unionized  environ¬ 
ment,  these  relations  are  explicitly  described  in  the  collective  bargaining  agree¬ 
ment. 

Leadership  and  champion:  An  advocate  for  significant  change  who  can  serve  as 
the  focal  point  for  resource  allocation  and  decision  making,  and  as  a  buffer 
against  those  who  oppose  the  change. 

Entrepreneurial  culture  and  risk  taking:  An  organizational  culture  and  formal 
reward  system  that  tolerates  some  degree  of  failure,  and  that  encourages  a  cer¬ 
tain  degree  of  risk  taking. 

Adaptive  learning  culture:  An  organizational  culture  that  rewards  individuals 
and  work  groups  for  learning  about  the  organization’s  changing  environment 
and  formulating  ways  to  adapt  to  likely  changes. 

Interorganization 

Establish  and  manage  interorganizational  relations:  Consciously  managed  for¬ 
mal  contractual  agreements  and  informal  social  interactions  in  support  of  enter¬ 
prise  goals. 

User  groups  consensus  on  requirements:  Users  of  hardware  and  software  pro¬ 
vide  coherent  sets  of  requirements  to  assist  vendors  in  developing  technologies 
that  are  widely  applicable. 


Accounting 


Activity-based  accounting:  Product  costing  obtained  by  accumulating  cost  data 
for  each  activity  performed  by  an  organizational  unit. 


Policy 


U.S.  Government 

Computer  Acquisition  Logistic  Support  (CALS):  An  integrated  system  of  sys¬ 
tems  that  can  create,  transform,  store,  transmit,  and  use  technical  information  as 
it  evolves  through  the  design,  manufacture,  and  support  of  defense  weapon  sys¬ 
tems  and  equipment.  The  system  is  intended  to  enable  the  Department  of 
Defense  to  design  better  and  more  reliable  weapon  systems  more  quickly  and 
less  expensively;  to  manage  its  essential  configuration  in  near  real-time;  and  to 
plan,  acquire,  and  deliver  its  essential  follow-on  logistic  support  more  promptly, 
economically,  accurately,  and  effectively. 

Acquisition  regulations:  Government  regulations  that  dictate  the  purchase  pro¬ 
cedures  between  the  Government  and  its  suppliers,  or  between  Government 
suppliers  and  their  subcontractors. 

Certification  of  product  and  process:  Government  regulations  concerning  what 
aspects  of  product  characteristics  and  manufacturing  processes  must  be 
recorded  and  certified  to  meet  criteria  determined  by  the  government. 

Certification  of  people:  Government  regulations  concerning  the  special  qualifi¬ 
cations  needed  by  personnel  engaged  in  particular  aspects  of  manufacturing  of 
goods  purchased  by  the  government. 

International 

Harmonize  trading  practices:  The  development  of  true  international  standards, 
as  opposed  to  unique  flavors  of  standards  for  different  countries 
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APPENDIX  E.  STANDARDS  AND  TECHNOLOGIES 
STATUS  CRITERIA 


These  1 1  criteria  were  obtained  from  the  National  Institute  of  Standards  and  Tech¬ 
nology  (NIST)  and  the  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX)  Open  System  Environment  (OSE),  with  some  additions  and  modifications  by  the 
Institute  for  Defense  Analyses  team. 

1 .  Specification  Availability:  A  high  evaluation  indicates  that  the  specification  is 
publicly  available  from  well-known  sources,  such  as  the  International  organi¬ 
zation  for  Standardization  (ISO),  the  American  National  Standards  Institute 
(ANSI),  the  National  Technical  Information  Services  (NTIS),  the  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE),  or  major  publishing  houses.  A 
medium  evaluation  indicates  that  the  specification  is  available,  but  from  lesser 
known  sources.  A  low  evaluation  indicates  the  specification  is  generally 
unavailable. 

2.  Level  of  Consensus:  A  low  evaluation  is  given  to  specifications  that  are  pro¬ 
prietary,  specifications  that  are  not  standard,  specifications  that  may  be  in  the 
process  of  becoming  a  standard  (e.g.,  standards  committee  work-in-progress), 
or  that  are  widely  available  across  various  hardware/software  platforms.  This 
criterion  is  the  same  as  the  NIST  Level  of  Consensus  and  similar  to  POSIX 
Openness,  Stage  of  Completion  and  Geographic  Scope  of  Consensus. 

3.  Product  Availability:  A  low  evaluation  is  given  to  specifications  for  which 
only  a  very  few  proprietary  products  are  available.  High  evaluations  are  given 
to  specifications  for  which  there  is  a  wide  variety  of  products  available  from 
various  vendors  across  different  application  platforms.  Medium  evaluations 
are  assigned  to  specifications  that  may  be  proprietary  but  have  many  products 
available  from  a  variety  of  vendors,  or  that  are  public  domain  specifications 
with  products  readily  available.  This  criterion  is  identical  to  NIST  Product 
Availability. 

4.  Completeness-.  A  specification  is  evaluated  on  the  degree  to  which  it  defines 
and  covers  key  features  necessary  in  supporting  its  intended  functional  area  or 
service.  This  criterion  is  identical  to  NIST  Completeness  and  similar  to 
POSIX  Functional  Scope. 

5.  Maturity:  Refers  to  the  underlying  technology  of  a  specification.  A  high  eval¬ 
uation  indicates  that  it  is  well  understood  (e.g.,  a  reference  model  is  well 
defined,  appropriate  concepts  of  the  technology  are  in  widespread  use,  the 
technology  may  have  been  in  use  for  many  years,  a  formal  mathematical 


model  is  defined.)  A  low  evaluation  indicates  that  it  may  be  based  on  technol¬ 
ogy  that  has  not  been  well  defined  and  may  be  relatively  new.  This  criterion  is 
identical  to  NIST  Maturity. 

6.  Stability:  A  high  evaluation  means  that  the  specification  is  very  stable,  that  no 
changes  are  expected  within  the  next  two  years.  A  low  evaluation  indicates 
that  significant  or  many  changes  are  expected  within  a  relatively  short  time,  or 
that  incompatibilities  exist  between  current  and  expected  releases  of  the  spec¬ 
ification.  An  medium  evaluation  is  given  to  those  specifications  that  may  have 
changes  forthcoming  to  replace  or  deprecate  features  in  the  existing  specifica¬ 
tions.  This  criterion  is  identical  to  NIST  Stability  and  POSIX  Stability. 

7.  De  facto  usage:  The  likelihood  that  a  vendor  will  independently  propose  prod¬ 
ucts  that  conform  to  this  specification  whether  or  not  a  reference  specification 
is  stated  in  the  procurement  documents.  A  high  evaluation  indicates  that  most 
proposed  products  will  conform  to  the  specification.  A  low  evaluation  indi¬ 
cates  that  it  is  unlikely  that  the  vendor  will  propose  products  based  on  the 
specifications.  A  medium  evaluation  indicates  that  vendors  could  go  either 
way.  This  criterion  is  identical  to  NIST  De  Facto  Usage. 

S.  Problem-freeness  (limitation-free ness):  A  low  evaluation  is  assigned  to  spec¬ 

ifications  with  severe  restrictions  on  use  or  capabilities  (e.g.,  licensing 
restrictions)  or  known  problems  too  difficult  or  too  numerous  to  overcome 
(e.g.,  new  releases  of  the  specification  are  not  compatible  with  previous 
releases,  or  not  enough  is  covered  in  the  standard  to  be  useful),  A  medium 
evaluation  is  given  to  those  specifications  that  require  some  minor  additional 
facility  in  order  to  be  fully  effective  in  their  intended  environment.  This  crite¬ 
rion  is  the  same  as  NIST  Problems/Limitations  and  includes  POSIX  Available 
for  Unencumbered  Implementation. 

9.  Conformance  testing:  A  high  evaluation  indicates  that  conformance  testing 
tools  are  publicly  available.  A  medium  evaluation  indicates  either  that  plans 
are  being  made  to  provide  publicly  available  conformance  testing  or  that  some 
private  initial  work  is  under  way.  A  low  evaluation  indicates  that  no  conform¬ 
ance  testing  plans  are  being  developed. 

1 0.  Future  P Ians:  A  high  evaluation  indicates  either  that  large-scale  development 
efforts  are  being  planned,  or  that  the  specification  will  continue  to  be  imple- 


# 
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merited  on  a  wide-scale  basis.  A  low  evaluation  indicates  that  development  is 
not  planned,  and  the  specification  is  not  expected  to  be  implemented. 

Predominance:  A  high  evaluation  indicates  that  there  is  no  competition  to  the 
specification  in  its  targeted  functional  area,  or  that  the  specification’s  imple¬ 
mentations  overwhelmingly  control  market  share  with  respect  to  competition. 
A  medium  evaluation  indicates  that  there  are  viable  alternatives  to  the  speci¬ 
fication.  A  low  evaluation  indicates  that  other  alternatives  are  available  and 
are  much  more  widely  accepted. 
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LIST  OF  ACRONYMS 


ABC 

ACSE 

AD 

ADE 

ADP 

ADPS 

ADSRS 

ADW 

AEP 

AFS 

AIAG 

ALC 

AMICE 

AMT 

ANSA 

ANSI 

AOM 

AP 

API 

APM 

APP 

APT 

AQES 

ASCII 

ASIC 

ASN.l 

ASPC 

ATA 

ATE 

BFM 


Activity  Based  Costing 

Association  Control  Service  Element 

Application  Development 

Advanced  Development  Environment 

Automated  Data  Processing 

Application  Development  Project  Support 

Automated  Drawing  Storage  and  Retrieval  System 

Application  Development  Workbench 

Application  Environment  Profile 

Andrew  File  System 

Automotive  Industry  Action  Group 

Air  Logistic  Center 

European  Computer  Integrated  Manufacturing  (CIM)  Architecture 

Advanced  Manufacturing  Technology 

Advanced  Network  Systems  Architecture 

American  National  Standards  Institute 

Application  Object  Model 

Application  Protocol 

Application  Program  Interface 

Architecture  Projects  Management 

Application  Portability  Profile 

Accredited  Portable  Operating  System  Interface  for  Computer  Environ¬ 
ments  (POSIX)  Testing 

Advanced  Quality  Engineering  System 
American  Standard  Code  for  Information  Interchange 
Application-Specific  Integrated  Circuits 
Abstract  Syntax  Notation  One 

Automated  Semiconductor  Planning  and  Control  System 
Airline  Transportation  Association 
Advanced  Tactical  Fighter 
Business  Flow  Management 


Acronyms- 1 


BOM 

BSD 

CACS 

CAD 

CAE 

CALS 

CAM 

CAM-I 

CAMO 

CAPP 

CASE 

CAx 

CBEMA 

CCITT 

CCR 

CCS 

CCIP 

CD 

CDF 

CDM 

CDRL 

CE 

CFl 

CFIMJ 

COM 

Cl 

CIE 

CIM 

CIO 

CIPT 

CIS 

CISTAR 

CITIS 

CLOS 

CMIP 


Bill  of  Materials 

Berkeley  Software  Distribution 

Corporate  Information  Management  (CIM)  Application  Consulting  Servic¬ 
es 

Computer-Aided  Design 
Computer-Aided  Engineering 
Computer  Acquisition  Logistic  Support 
Computer-Aided  Manufacturing 
Computer-Aided  Manufacturing-International 
Computer-Aided  Miscellaneous  Operations 
Computer-Aided  Production  Planning 
Computer-Aided  Software  Engineering 
Computer-Aided  Design/Manufacturing/Engineering 
Computer  and  Business  Equipment  Manufacturers  Association 
International  Telegraph  and  Telephone  Consultative  Committee 
Commitment,  Concurrency,  and  Recovery  (protocol) 

Common  Communications  Support 

Computer-Aided  Design  (CAD)/Computer-Aided  Manufacturing  (CAM) 
Integration  Plan 

Collision  Detection;  Committee  Draft 
Common  Data  Format 
Common  Data  Model 
Contract  Data  Requirement  List 
Concurrent  Engineering 

Computer-Aided  Design  (CAD)  Framework  Initiative 

Computer-Aided  Design  (CAD)  Framework  Initiative  in  Japan 

Computer  Graphics  Metafile 

Continuous  Improvement 

Computer  Integrated  Enterprise 

Computer  Integrated  Manufacturing 

Computer  Integrated  Operations 

Component  Integrated  Product  Team 

Center  for  Integrated  Systems 

Computer  Integrated  Systems,  Technologies,  and  Resources 
Contractor  Integrated  Technical  Information  Service 
Common  Lisp  Object  System 
Common  Management  Information  Protocol 


Acronyms-2 


CMOT 

CNMA 

COF 

CORBA 

COS 

COTS 

CPI 

CPTR 

CSMA 

CSRC 

CUA 

cv 

CVS 

DAC 

DAE 

DARPA 

DART 

DBMS 

DCE 

DDE 

DDM 

DEC 

DECMACS 

DES 

DETC 

DIS 

DFS 

DME 

DML 

DMU 

DNA 

DNS 

DoD 

DOE 

DOME 

DP 


Common  Management  Information  Protocol  (CMIP)  Over  Transmission 
Control  Protocol  (TCP)/Internet  Protocol  (IP) 

Communications  Network  for  Manufacturing  Applications 
Customer  Order  Fulfillment 

Common  Object  Request  Broker:  Architecture  and  Specification 

Corporation  of  Open  Systems 

Commercial  off  the  Shelf 

Common  Programing  Interface 

Common  Problem/Task  Report 

Carrier  Sense  Multiple  Access 

Computer  Acquisition  Logistic  Support  (CALS)  Shared  Resource  Center 

Common  User  Access 

Computer  Vision 

Central  Version  System 

Design  Automation  Conference 

Distributed  Applications  Environment 

Defense  Advanced  Research  Projects  Agency 

Data  Archival  and  Retrieval 

Database  Management  Systems 

Distributed  Computing  Environment 

Dynamic  Data  Exchange 

Distributed  Data  Management 

Digital  Equipment  Corporation 

Development  Engine  Change  Management  and  Control  System 

Data  Encryption  Standard 

Data  Exchange  Technical  Center 

Draft  International  Standard 

Distributed  File  System 

Distributed  Management  Environment 

Data  Manipulation  Language 

Digital  Mock  Up 

Defense  Nuclear  Agency 

Domain  Name  System 

Department  of  Defense 

Distributed  Objects  Everywhere 

Distributed  Object  Management  Facility 

Draft  Proposal 


Acronyms- 3 


DPA 

Digital  Pre- Assembly 

DPU 

Defects  Per  Unit 

DR  PI 

Design  Representation  Programming  Interface 

DRC 

Database  Relational  Common 

DS 

Directory  Services 

DSD 

Design  Support  Database 

DSOM 

Distributed  System  Object  Management 

EAP 

Electronic  Assembly  Plant 

EBCDIC 

Extended  Binary  Coded  Decimal  Interchange  Code 

ECAD 

Electronic  Computer-Aided  Design 

ECMA 

European  Computer  Manufacturers  Association 

ECN 

Engineering  Change  Notice 

ECO 

Engineering  Change  Order 

EDI 

Electronic  Data  Interchange 

EDIF 

Electronic  Data  Interchange  Format 

EDIFACT 

Electronic  Data  Interchange  for  Administration 

EDS 

Electronics  Data  Systems 

EGP 

Exterior  Gate  Protocol 

El 

Enterprise  Integration 

EEI 

External  Environment  Interface 

EEO 

Equal  Employment  Opportunity 

EIA 

Electronics  Industry  Association 

EIF 

Engineering  Information  Facility 

EIP 

Enterprise  Integration  Program 

EIS 

Engineering  Information  System 

EISWG 

Engineering  Information  System  Working  Group 

EIT 

Enterprise  Integration  Technologies 

ENE 

Enterprise  Networking  Event 

EPA 

Enhanced  Performance  Architecture;  Environmental  Protection  Agency 

ER 

Entity-Relationship 

ESG 

Electronic  Systems  Group 

ESPRIT 

European  Strategic  Programme  for  Research  and  Development  in  Informa¬ 
tion  Technology 

EWOS 

European  Workshop  on  Open  Systems 

FAP 

Formats  and  Protocols 

FARS 

Federal  Acquisition  Regulations 

FCS 

Factory  Control  System 

Acronyms-4 


FDDI 

FIPS 

FIPS  Pubs 

FOF 

FTAM 

FTE 

FTP 

GE 

GEAE 

GGP 

GKS 

GM 

GM-C4 


GMD 

GNMP 

GOSIP 

GUI 

HP 

I/O 

lAB 

lAE 

IBM 

IC 

ICAM 

ICAM-FoE 

ICMP 

ICSI 

IDA 

IDE 

IDEF 

IDL 

IDS 

lEC 

IEEE 

lEF 


Fiber  Data  Digital  Interface 

Federal  Information  Processing  Standards 

Federal  Information  Processing  Standards  Publications 

Factory  of  the  Future 

File  Transfer,  Access,  and  Management 

Full  Time  Equivalent 

File  Transfer  Protocol 

General  Electric 

General  Electric  Aircraft  Engines 
Gateway-to-Gateway  Protocol 
Graphical  Kernel  System 
General  Motors 

General  Motors  Computer-Assisted  Design  (CAD)/Computer-Assisted 
Manufacturing  (CAM)/Computer-Assisted  Engineering  (CAE)/Computer- 
Integrated  Manufacturing  (CIM) 

Gesellschaft  fur  Mathematik  und  Datenverarbeitung  MBH  (German) 

Government  Network  Management  Profile 

Government  Open  Systems  Interconnection  Profile 

Graphical  User  Interface 

Hewlett  Packard 

Input/Output 

Internet  Activities  Board 

International  Aero  Engines 

International  Business  Machines 

Integrated  Circuit 

Integrated  Computer-Aided  Manufacturing 

Integrated  Computer-Aided  Manufacturing  Factory  of  the  Future 

Internet  Control  Message  Protocol 

International  Coding  System  Identifier 

Institute  for  Defense  Analyses 

Inspection  Data  Entry 

Integrated  Computer-Aided  Manufacturing  (ICAM)  Definition  Language 

Interface  Definition  Language 

Integrated  Design  Support  System 

International  Electrotechnical  Committee 

Institute  of  Electrical  and  Electronics  Engineers 

Information  Engineering  Facility 


Acronyms-5 


lEW 

IGES 

IIS 

IISS 

ILS 

IM 

IMPPACT 

INTEROP 

IP 

IPD 

IPDS 

IPG 

IPMT 

IPO 

IRD 

IRDS 

IRR 

IS 

ISA 

ISAM 

ISO 

ISDN 

ISEC 

ISO 

ISST 

ITC 

m 

IWSDB 

JAEC 

JSD 

JIT 

KBS 

LAN 

LAPI 

LAWS 


Information  Engineering  Workbench 
Initial  Graphics  Exchange  Specification 
Integrating  Infrastructure 
Integrated  Information  Support  System 
Integrated  Logistics  Support 
Integrated  Model 

Integrated  Modeling  of  Products  and  Processes  Using  Advanced  Computer 
Technologies 
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Internet  Protocol 

Integrated  Product  Development 

Integrated  Part  and  Document  System 

Integration  Product  Group 

Integrated  Product  Management  Team 

Initial  Graphics  Exchange  Specification  (IGES)/Product  Data  Exchange 
Standard  (PDES)  Organization 

Information  Resource  Dictionary 
Information  Resource  Dictionary  System 
Internal  Rate  of  Return 
Information  Systems 

Integrated  Systems  Architecture;  Instrument  Society  of  America 

Indexed  Sequential  Access  Method 

Industrial  Sector  Division 

Integrated  Services  Digital  Network 

Information  Systems  Corporate  Action  Group 

International  Organization  for  Standardization 

Information  Systems  Study  Team 

Inter- Tool  Communication 

Industrial  Technology  Institute 

Integrated  Weapons  Systems  Database 

Japan  Aero  Engine  Company 

Jackson  System  Design 

Just-in-Time 

Knowledge-Based  Systems 
Local  Area  Network 
Layered  Application  Program  Interface 
Lockheed  Advanced  Wiring  System 


Acronyms-6 


LDRO  Long  Data  Reference  Option 

LISP  List  Processing 

MANTECH  Manufacturing  Technology 

MAP  Manufacturing  Automation  Protocol 

MBR  Model-Based  Reasoning 

MCAD  Mechanical  Computer-Aided  Design 

MCAE  Mechanical  Computer-Aided  Engineering 

MCC  Microelectronics  and  Computer  Technologies  Corporation 

MCO  Manufacturing  Change  Order 

MCS  Material  Control  System 

MHS  Message  Handling  Service 

MIP  Methods  Improvement  Program 

MIS  Management  Information  System 

MIT  Massachusetts  Institute  of  Technology 

MKS  Manufacturing  Knowledge  System 

MMS  Manufacturing  Message  Specification 

MP&RS  Material  Planning  and  Release  System 

MPEP  Mass  Properties  Estimation  Procedures 

MRP  Manufacturing  Resource  Planning 

MST  Microelectronics  Science  and  Technology 

MTUG  Manufacturing  Automation  Protocol  (MAP)/Technical  and  Office  Protocol 

(TOP)  User’s  Group 

NAS  Network  Applications  Support 

NC  Numerical  Control 

NCAT  National  Center  for  Advance  Technologies 

NCC  National  Computer  Centre;  Network  Control  Center 

NCMS  National  Center  for  Manufacturing  Sciences 

NCS  Network  Computing  System 

NCSL  National  Computer  Systems  Laboratory 

n.d.  no  date  [available] 

NDDL  Neutral  Data  Definition  Language 

NDL  Network  Database  Language 

NDML  Neutral  Data  Manipulation  Language 

NEMA  National  Equipment  Manufacturers  Association 

NFS  Network  File  System 

NGC  Next  Generation  Controller 


NIAM  Nijssen  Information  Analysis  Methodology  [or  Normalized  lAM] 


Acronyms-7 


NIH 

Not  Invented  Here 

NISC 

Northrop  Information  Services 

NIST 

National  Institute  of  Standards  and  Technology 

NM 

Network  Management 

NTIS 

National  Technical  Information  Service 

NTM 

Network  Transaction  Manager 

ODA 

Open  Document  Architecture 

ODIF 

Open  Document  Interchange  Format 

ODL 

Open  Document  Language 

ODP 

Open  Distributed  Processing 

ODPC 

Open  Distributed  Processing  Consortium 

ODPTI 

Open  Distributed  Processing  Testbed  Initiative 

OIF 

Operational  Integration  Framework 

OIW 

Open  Systems  Interconnection  (OSI)  Implementor’s  Workshop 

OLE 

Object  Linking  and  Embedding 

OMA 

Object  Management  Architecture 

OMG 

Object  Management  Group 

OO-CORE 

Object-Oriented,  Change-Oriented  Reference  Environment 

OODB 

Object-Oriented  Database 

OODBMS 

Object-Oriented  Database  Management  System 

00-SQL 

Object-Oriented  SQL 

OP 

Organization  Profile 

OPs 

Organizations  and  Programs 

ORB 

Object  Request  Broker 

OSA 

Office  System  Architecture 

OSAT 

Office  for  the  Study  of  Automotive  Transportation 

OSE 

Open  Systems  Environment 

OSF 

Open  Software  Foundation 

OSHA 

Occupational  Safety  and  Health  Administration 

OSI 

Open  Systems  Interconnection 

PARC 

Palo  Alto  Research  Center 

PC 

Personal  Computer 

PCB 

Printed  Circuit  Board 

PCI 

Protocol  Control  Information 

PCTE 

Portable  Common  Tool  Environment 

PDCM 

Product  Data  Conceptual  Model 

PDCS 

Product  Drawing  Control  System 

Acronyms-8 


PDE 

Product  Data  Exchange 

PDES 

Product  Data  Exchange  Standard 

PDS 

Product  Definition  System 

PEX 

Programmer’s  Hierarchical  Interactive  Graphics  System  (PHIGS)  Exten¬ 
sion  to  X  Window 

PHIGS 

Programmer’s  Hierarchical  Interactive  Graphics  System 

PM 

Presentation  Manager 

POMS 

Process-Oriented  Management  System 

POSIX 

Portable  Operating  System  Interface  for  Computer  Environments 

PWA 

Printed  Wire  Assemblies 

QA 

Quality  Assurance 

QFD 

Quality  Function  Deployment 

R&T 

Research  and  Technology 

RDA 

Remote  Database  Access 

RDBMS 

Relational  Database  Management  System 

REF 

Repository  Enablement  Facility 

RFC 

Request  for  Comment 

RFl 

Request  for  Information 

RFP 

Request  for  Proposal 

RFT 

Request  for  Technology 

RIA 

Robot  Institute  of  America 

RM 

Repository  Manager 

ROI 

Return  on  Investment 

ROM 

Read-Only  Memory 

ROSE 

Remote  Operation  Service  Element 

RPC 

Remote  Procedure  Call 

SAA 

Systems  Application  Architecture 

SADT 
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